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EXECUTIVE  SUMMARY 


Function  allocation  is  “the  process  of  deciding  how  system  functions 
shall  be  implemented — by  human,  by  equipment,  or  by  both — and  as¬ 
signing  them  accordingly”  (Beevis,  1992).  Function  allocation  deci¬ 
sions  define  the  roles,  functions,  and  tasks  performed  by  human  opera¬ 
tors  and  maintainers.  Thus,  function  allocation  is  linked  to  issues  of 
automation  and  personnel  reduction,  as  well  as  to  questions  about  hu¬ 
man  responsibility  for  the  safe  and  effective  operation  of  a  system.  For 
these  reasons,  some  human  factors  specialists  argue  that  function  allo¬ 
cation  is  the  most  important  step  in  human  engineering.  In  1992,  Re¬ 
search  Study  Group  14  on  Analysis  Techniques  for  Man-Machine  Sys¬ 
tem  Design  (RSG.14)  of  NATO  Defence  Research  Group  Panel  8  on 
the  Defence  Applications  of  Human  and  Bio-Medical  Sciences  com¬ 
pleted  a  review  of  human  engineering  analysis  techniques  (Beevis, 
1992).  Six  main  classes  of  human  engineering  analyses  were  identified 
(see  figure  on  next  page).  In  completing  its  work,  RSG.14  concluded 
that  function  allocation  was  the  weakest  of  the  human  engineering 
techniques  reviewed  and  recommended  that  a  workshop  be  organized  to 
review  the  topic.  Presentations  on  function  allocation  were  solicited 
from  the  nations  that  participated  in  RSG.14,  and  a  workshop  was  or¬ 
ganized  and  held  on  November  29-30,  1994,  hosted  by  the  TNO  Human 
Factors  Research  Institute,  Soesterberg,  The  Netherlands. 

The  aim  of  the  workshop  was  to  review  the  need  for  function  alloca¬ 
tion,  the  maturity  of  available  techniques,  and  the  need  for  additional 
research  in  the  area,  as  well  as  to  make  recommendations  to  human 
factors  practitioners.  Seventeen  presentations  by  human  factors  special¬ 
ists  from  academia,  government,  and  industry,  as  well  as  by  engineers 
and  project  managers,  reviewed  the  state  of  the  art  in  function 
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Six  main  classes  of  human  engineering  analyses. 
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allocation.  The  papers,  which  are  reported  in  these  proceedings,  address 
issues  of  function  allocation,  discuss  methods  for  evaluating  function 
allocation  decisions,  and  describe  state-of-the-art  applications  of  func¬ 
tion  allocation  techniques.  The  presentations  provided  the  basis  for 
workshop  discussions  on  areas  where  further  research  is  required  and  on 
promising  approaches  to  function  allocation  that  can  be  used  by  practi¬ 
tioners. 

Function  allocation  techniques  that  were  reviewed  included  a  simple 
dichotomous  choice  between  human  and  machine,  a  two-stage  alloca¬ 
tion  process,  iterative  modification  of  function  allocations,  and  reverse 
engineering  of  operator  tasks.  It  appeared  that  users  compensate  for  the 
predictive  weakness  of  available  function  allocation  techniques  by  con¬ 
centrating  on  verifying  the  implications  of  the  allocation  decisions  for 
system  performance  or  operator  workload.  Methods  employed  for  this 
verification  include  computer  simulations  of  operator  workload,  human- 
in-the-loop  simulations,  or  trials  using  rapid  prototypes  or  functional 
mock-ups  to  predict  human  or  system  performance.  Examples  of  areas 
of  applications  that  were  discussed  include  aircraft,  ships,  land  vehicles, 
and  command  and  control  systems.  Some  of  the  applications  of  automa¬ 
tion  reviewed  permit  flexible  reallocation  of  functions  depending  on  the 
operator’s  tasks  or  mission  events. 

The  workshop  drew  the  following  conclusions: 

•  Problems  of  terminology  remain,  particularly  when  human  factors 
specialists  communicate  with  those  in  other  engineering  disci¬ 
plines. 

•  Function  allocation  is  not  an  isolated  activity  and  must  be  incorpo¬ 
rated  in  the  development  process  early  enough  to  inllucncc  design 
decisions  and  to  permit  iteration. 

•  No  single  technique  is  available  that  deals  with  all  of  the  issues 
involved  in  assigning  functions  to  humans. 

•  Function  allocation  decisions  must  be  validated  by  predictions  of 
operator  workload  or  system  performance  and  the  allocation  deci¬ 
sions  revised  if  necessary  in  an  iterative  approach. 

•  Little  research  activity  is  devoted  currently  to  human  behavior  in 
systems  operation  or  to  improving  human  factors  engineering 
techniques. 
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Executive  Summary 


•  Several  important  research  issues  relate  to  function  allocation,  in¬ 
cluding:  adaptive  function  allocation  and  the  role  of  humans;  the 
validity  of  methods  for  testing  the  implications  of  function  alloca¬ 
tion;  and  the  development  of  a  taxonomy  that  relates  factors  affect¬ 
ing  function  allocation,  the  problern  domain,  and  available  function 
allocation  techniques. 


REFERENCE 

Beevis,  D.  (Ed.).  (1992).  Analysis  techniques  for  man-machine  sys¬ 
tems  design  (NATO  Technical  Report  AC/243  [Panel  8]  TR/7,  Vols.  1 
&  2).  Brussels:  NATO  Defence  Research  Group. 


ACKNOWLEDGEMENTS 


Reviewing  (he  stale  ol  the  art  and  identifying  the  need  for  additional 
research  arc  activities  needed  to  maintain  the  quality  of  research  at  an 
adequate  level.  This  report  is  a  result  of  such  a  prcKXss  and  is  intended 
to  illustrate  the  need  for  improving  the  function  alliK'alion  prcK'ess. 

The  quality  of  the  function  allocation  prcK'css  was  discussed  in  the 
workshop  on  Improving  Function  Allocation  for  Integrated  System 
Design,  which  followed  logically  from  the  work  conducted  by  the 
NATO  Defence  Rc.scarch  Group,  Panel  8,  Rc.scarch  Study  Group  14  on 
Analysis  Techniques  for  Man-Machine  Systems  Design.  The  members 
of  the  rc.scarch  group,  B.  Doring,  E.  Nord0,  D.  F.  Streets,  R.  Bosl,  V. 
R.  Oherman,  J.-P.  Papin,  H.  Schuffcl,  and  D.  Beevis,  prepared  material 
and  Conned  a  committee  to  organize  the  workshop.  This  initiative  was 
encouraged  hy  Dr.  A.  van  Mcctcrcn,  Director  of  Panel  8,  and  was  sup¬ 
ported  hy  Dr.  K.  Gardner  of  the  NATO  Defence  Research  Section. 

Special  thanks  arc  due  to  the  following:  the  TNO  Human  Factors 
Rc.scarch  Institute,  Soeslcrbcrg,  The  Netherlands,  which  hosted  the 
meeting  and  whose  support  .staff  did  an  excellent  joh  of  providing  all 
the  necessary  facilities;  secretaries  W.  RcxxJcnhurg  and  N.  Karsli,  who 
did  most  of  the  work  to  prepare  the  text  for  publication;  Dr.  J. 
McDaniel  of  the  US  Air  Force  Armstrong  Laboratory,  who  provided  the 
1951  report  edited  by  Paul  Fills  lhal  originalcd  discussion  of  ihc  allcKa- 
tion  of  functions  between  human  and  machine,  and  who  obtained  per¬ 
mission  for  us  to  publish  it;  and  Dr.  J.  E.  Lincoln  of  CSF^RIAC,  who 
.served  as  the  technical  editor  (or  this  edition. 

Dk.  H.  SCHUFFEL 

Chairman  of  the  Ori^anizini*  Committee. 

Workshop  on  Improving  h unction  Allocation  for 
In  tcf*  ra  t e<l  Systems  Dcsig  n 


INTRODUCTION 


D.  Beevis,  P.  J.  M.  D.  Essens,  and  H.  Schuffel 


Function  alUxalion  tries  to  balance  attempts  to  ineehani/.e  or  automate 
as  many  system  functions  as  possible  by  seeking  roles  and  tasks  for 
bumans  that  make  best  use  of  tbeir  eapabilities  while  reeognizing  hu¬ 
man  limitations.  Typically,  decisions  about  the  roles,  functions,  iuid 
tasks  performed  by  humans  in  a  system  arc  made  implicitly  in  the  de¬ 
sign  pr(x:css  through  the  selection  or  development  of  equipment  and 
software.  While  this  approach  is  logical,  in  that  mechanization  is  usu¬ 
ally  beneficial  (Chapanis,  1970),  such  decisions  can  ignore  a  systematic 
consideration  of  the  capabilities  and  limitations  of  humans  and  how 
these  affect  the  performance  of  the  system.  Function  allocation  provides 
the  basis  for  subsequent  human  factors  efforts  relating  to  operator  task 
analysis  and  dc.scription,  operator  pcrfomiancc  analysis,  display  aixl 
control  selection  or  design,  and  crew-station  design,  development,  and 
evaluation.  Thus,  function  allocation  docs  not  stand  alone,  hut  is  one  of 
several  iterative  stages  in  the  implementation  of  ergonomics  or  human 
factors  engineering  in  the  design  of  human-machine  systems  (sec  llgurc 
on  next  page). 

The  concept  of  formal  function  allocation  is  usually  attributed  to  the 
suggestion  hy  Paul  Fitts  and  his  colleagues  at  the  Ohio  State  Univer¬ 
sity  Research  Foundation  that  system  functions  could  he  assigned  hy 
identifying  those  areas  in  which  the  human  is  superior  to  the  machine 
and  vice  versa  (Kantowitz  &  Sorkin,  1987).  That  seminal  contribution 
to  the  topic  of  function  allocation,  comprising  a  chapter  from  a  review 
of  human  engineering  for  air  traffic  control  (Fitts,  1951),  has  been  rc- 
pRxJuccd  as  Ap|xmdix  I  to  these  prcK'cedings,  in  order  to  make  it  more 
accessible  to  the  reader.  By  the  late  195()s,  the  “fatts  Last”  approach  of 
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comparing  human  and  machine  capahi lilies  had  been  incorporated  into  a 
number  ol  human  engineering  guidelines  (Javii/,  1956;  Slarkcy,  1959; 
Van  Colt  &  Allman,  1956).  It  was  .soon  recogni/.ed,  however,  that 
lunctions  should  nol  he  alloealed  on  the  basis  of  a  direct  comparison  of 
human  and  machine  capahi  lilies,  because  machines  are  built  to  com¬ 
plement  humans,  nol  to  duplicate  them  (Fills,  1962;  Jordan,  1963). 
Since  then,  .several  dillereni  approaches  have  been  advocated  (Singleton, 
1974): 

•  conducting  a  comparative  assessment  of  human  and  machine  per- 
fomiance; 

•  performing  economic  cost  comparisons  of  human  and  machine; 

•  designing  tasks  to  exploit  complementary  human  and  machine 
characlerislies 

•  grading  human  tasks  to  match  individual  differences; 

•  hasing  human  functions  on  system  functions  and  supplementing 
them  with  machines; 

•  permitting  humans  to  vary  their  degree  of  participation  in  the  .sys¬ 
tem  through  Ilexihle  delegation  of  computer  facilities  . 

Throughout  the  evolution  of  the  approach  to  function  alkK'ation, 
opinions  have  varied  widely  about  its  utility.  It  has  been  described  as 
“one  of  the  Hrsi  and  most  important  problems  in  human-machine  sys¬ 
tems  design,”  but  one  which  is  not  helped  hy  general  statements  about 
human  and  machine  capabilities  (Chapanis,  1965).  Function  allcKation 
has  also  been  desenbed  as  a  “llction”  and  an  “artifact,”  a  “purely  post- 
hoc,  descriptive  analysis  generating  lew,  if  any,  particular  results” 
(Imid,  1993).  Such  criticism  may  he  justilled  in  some  cases.  Compared 
with  the  other  clas.scs  of  human  engineering  analyses,  the  techniques 
available  for  function  alkx:ation  have  not  matured:  most  use  an  ordinal 
level  of  measurement;  lew  such  analyses  can  he  related  directly  to  sys¬ 
tem  performance  requirements;  and  the  procedures  available  for  quality 
control  are  limited  (IJeevis,  1992). 

At  the  same  lime,  knowledge  of  available  techniques  is  limited  be- 
cau.se  of  the  way  function  alloeation  is  treated  in  the  human  factors  lit 
erature.  Kanlowii/  and  Sorkin  ( 1987)  have  suggested  that  elesigners  con¬ 
tinue  to  u.se  tables  of  relative  merit  either  because  they  do  not  liml 
criticisms  of  the  approach  convincing,  or  “because  they  arc  nol  familiar 
with  anything  belter.”  Many  human  factors  sources  illustrate  only  the 
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earliest  approach  to  function  allocation  using  a  tabular  comparison  of 
human  and  machine  abilities  (e.g.,  US  Dept,  of  Defense,  1987).  Few 
human  factors  handbooks  refer  to  the  other  approaches,  such  as  the  use 
of  orthogonal  rating  scales  to  create  a  two-dimensional  comparison  of 
human  and  machine  capabilities  (Price,  1985),  or  a  five-step  process  for 
allocating  functions  that  takes  into  account  engineering  constraints 
(Meister,  1985). 

Given  the  limitations  of  available  techniques  and  the  lack  of  coverage 
of  some  of  them  in  the  human  factors  literature,  it  is  not  surprising  that 
surveys  show  a  lower  level  of  application  of  formal  comparative  func¬ 
tion  allocation  techniques  than  of  other  human  engineering  techniques 
such  as  operator  task  analysis  (Beevis,  1987;  1992).  One  goal  of  the 
workshop  at  which  the  papers  in  this  volume  were  presented  was  to 
contribute  to  improving  the  application  of  function  allocation  tech¬ 
niques. 

As  discussed  by  Sheridan  in  the  keynote  paper  in  these  proceedings, 
the  development  of  increasingly  advanced  system  hardware  and  software 
makes  the  allocation  of  functions  more  complex  than  a  simple  di¬ 
chotomous  choice  between  human  and  machine.  The  other  papers  exam¬ 
ine  these  problems  in  more  detail,  discuss  methods  for  evaluating  the 
function  allocation  decisions  once  they  are  made,  and  report  state-of-the- 
art  applications  of  function  allocation  techniques. 
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ALLOCATING  FUNCTIONS  AMONG 
HUMANS  AND  MACHINES 

T.  B.  Sheridan 


Although  automation  is  improving  steadily,  it  is  difficult  to 
anticipate  all  the  problems  associated  with  its  implementa¬ 
tion.  An  approach  to  function  allocation  that  combines  human 
and  machine  functions  seems  the  best  solution.  Several  tech¬ 
niques  used  by  industrial  engineers  are  suited  to  the  analysis 
of  human  and  machine  tasks.  In  a  wide  variety  of  systems,  the 
human  tasks  are  associated  with  superx  ision.  A  number  of  re¬ 
search  topics  can  be  identified  with  this  type  of  function  allo¬ 
cation.  These  topics  include:  questions  of  attention  allocation 
and  operator  workload;  vi'av5  to  maintain  situation  awareness 
when  the  operator  is  not  in  the  loop:  the  need  for  computers 
to  maintain  models  of  the  user;  means  of  sustaining  operator 
trust  in  automation:  and  the  appropriate  architecture  for  the 
human-machine  system. 


ASSUMPTIONS 

First,  let  us  make  some  assumptions  about  human-machine  function 
allocation  (where  function  is  taken  here  to  mean  essentially  the  same 
thing  as  task,  though  some  people  prefer  a  decomposition  of  mission 
into  functions,  and  functions  into  tasks): 

•  Optimal  allocation  of  functions  is  easy,  if  one  has  well-defined 
mathematical  equations  for  the  behavior  of  all  human  and  machine 
functional  elements,  and  an  objective  function  that  includes  all  sa¬ 
lient  variables  is  also  available  in  mathematical  form.  Then  all  one 
has  to  do  is  find  a  simultaneous  solution  of  these  equations.  This 
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is  essentially  what  all  formal  optimization  does.  Unhappily,  these 
equations  are  seldom,  if  ever,  available, 

•  Human-machine  systems  (military  command  and  control  systems, 
domestic  transportation  and  traffic  control  systems  for  air,  sea,  rail 
and  highway  vehicles,  hospital  systems,  business  and  government 
information  systems,  etc.)  are  getting  steadily  more  complex. 
(Complexity  may  be  defined,  for  example,  by  the  Kolmogorov 
[1987]  algorithmic  information  measure,  the  shortest  possible  bi¬ 
nary  string  sufficient  to  describe  the  parts  of  a  system  plus  those 
sufficient  to  assemble  the  parts  and  perform  the  essential  operations 
of  the  system.)  In  addition  to  this  complexity  is  the  fact  that  hu¬ 
man-machine  systems  are  getting  steadily  more  distributed,  mean¬ 
ing  that  multiple,  isolated  agents  communicate  over  noisy,  delayed 
channels  to  allocate  resources  held  in  common  (Figure  1,1). 

•  There  is  no  commonly  accepted  allocation  methodology  (and  fm 
not  going  to  propose  one). 

It  is  an  accepted  fact  that  automation  is  getting  better  all  the  time. 
However,  this  means  that  (Kantowitz  &  Sorkin,  1987): 

•  The  human  must  become  a  monitor  of  automation.  However,  it  is 
well  known  that  the  human  is  a  poor  monitor — unless  aided  in  cer¬ 
tain  ways  that  are  discussed  below. 

•  Increased  automation  means  increased  training  requirements. 

•  Newly  automated  systems  have  bugs, 

•  Failure  of  automation  leads  to  loss  of  credibility  and  trust. 

•  Designers  tend  not  to  anticipate  new  problems  that  automation 
brings  with  it  (e.g.,  mode  errors  and  feelings  of  alienation,  both 
aspects  to  be  discussed  below). 

HISTORY:  COMPARISONS  AND  TECHNIQUES 

Historically,  Fitts  (1951)  was  among  the  first  to  suggest  criteria  for 
allocating  functions  among  people  and  machines.  My  abbreviation  of 
Fitts'  List  is  shown  in  Table  1.1. 

Many  others  followed  Fitts'  lead,  Meister  (1971)  suggested  a  straight¬ 
forward  procedure:  write  down  all  the  mixes  of  allocation  and  write 
down  all  the  applicable  criteria.  Following  this,  one  can  rank-order  all 
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observed  by 
both  A  and  B 


computer 

B 


operator 


observed 


observed  by  B 


delay  and  noise 
in  communication 


computer 

A 


operator 

A 


l^igurc  LI.  Distributed  decisionmaking.  (From  Telerohotic.s,  auto¬ 
mation,  and  human  supervisory  control  (Fig.  3.26],  by  T.  Sheridan, 
1992,  Cambridge,  MA:  MIT  Press;  after  DiCe.sare  &  Desrochers,  1991 . 
Copyright  0  1992  by  MIT  Press.  Reprinted  with  permission.) 
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Table  1.1.  Fitts’  List 


People  are  better  at: 

•  Detecting  small  amounts  of  visual,  auditory,  or  chemical 
energy 

•  Perceiving  patterns  of  light  or  sound 

•  Improvising  and  using  Hcxible  prcx'edures 

•  Storing  information  for  long  pericxJs  of  time,  and  recalling 
appropriate  parts 

•  Reasoning  inductively 

•  Exercising  judgment 

Machines  are  better  at: 

•  Responding  quiekly  to  control  signals 

•  Applying  great  force  smoothly  and  precisely 

•  Storing  information  hriefly,  erasing  it  completely 

•  Reasoning  deductively 

•  Doing  many  complex  operations  at  once 


combinations  of  allocation  mix  and  criteria  (how  well  each  allocation 
meets  each  criterion),  thus  determining  a  rank-order  score.  Alternatively, 
one  can  weight  the  relative  importance  of  each  criterion,  rate  each  mix 
on  each  criterion  and  multiply  hy  the  weight,  then  add  up  the  scores  for 
each  allocation  mix.  The  difficulties  in  any  such  direct  methods  include: 
hidden  assumptions,  unanticipated  criteria  considcratio^is,  nonindc- 
pcndcncc  of  criteria,  and  nonlincaritics  in  importance  functions 
(invalidating  the  simple  multiplication  of  weight  x  rating).  Price 
(1985,  1990)  provides  more  recent  reviews  of  the  function  allegation 
problem. 

Combining  automatic  with  human  functions  has  seemed  the  obvious 
solution.  After  all,  humans  and  machines  seem  complementary  in  what 
each  dexis  best.  The  cost  of  combining,  of  course,  is  the  overhead  of 
communicating  between  them  (in  terms  of  the  recording  and  the  display 
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and  control  device  software  and  hardware  to  move  information  from  one 
to  the  other). 

Analysis  of  a  given  job  in  tenns  of  task  and/or  functional  elements, 
and  their  logical  and  temporal  sequences,  is  amenable  to  many  tech¬ 
niques  that  have  been  used  by  industrial  engineers  for  years.  These  go 
by  many  names,  but  most  fit  relatively  simply  into  several  categories: 
( 1 )  operations/llow  process  diagrams,  similar  to  the  now  common  How 
charts  of  computer  software,  which  show  the  sequencing  of  logic  or 
causality  and  also  permit  feedback  loops;  (2)  body,  hand,  and  eye 
movement  maps,  showing  what  moves  where  in  two-  (or  even  three-) 
dimensional  space;  (3)  time  lines  showing  which  human  or  machine 
element  performs  what  action  at  what  time,  where  time  is  a  vertical  or 
horizontal  axis  (time  lines  have  difficulty  with  feedback  loops);  (4) 
transition  frequency/association  networks  and  matrices  (Markov  mod¬ 
els);  and  (5)  dynamie  computer  simulations  that  play  out  these  opera¬ 
tions  in  space  and  time  on  computer-graphic  screens  and  in  some  cases 
even  enable  the  observer  to  “be  there”  through  virtual  reality. 

The  Petri  net  is  a  relatively  new  version  of  the  first  category 
(operational/How  process  diagrams)  now  used  by  manufacturing  engi¬ 
neers  to  simulate  whieh  machine  is  performing  which  function  when. 
Figure  1 .2  shows  an  example. 

Levis,  Moray,  and  Hu  (1994)  make  use  of  Petri  nets  to  model  concur¬ 
rent  execution  of  tasks  by  people  and  machines  in  teamwork  operations 
and  to  evaluate  alternative  organizational  and  communication  structures. 
An  example  is  the  control  of  aircraft  from  the  time  of  leaving  the  gate 
through  taxi  to  the  point  of  takeoff,  and  the  reverse,  including  whether  a 
fixed  allocation  of  terminals  and  gates  to  each  ground  controller  is  better 
or  worse  than  a  more  flexible  one  that  changes  with  time  and  tries  to 
balance  workload.  As  Levis  ct  al.  point  out,  however,  currently  avail¬ 
able  techniques  do  not  model  dynamic  transitions  from  one  allocation  to 
another.  This  is  a  topic  of  current  research. 

SUPERVISORY  CONTROL 

A  recent  large-scale  application  of  task  analysis  was  made  to  every 
nuclear  power  plant  in  the  United  States,  mandated  by  the  government 
following  the  accident  at  Three-Mile  Island.  What  was  particularly  in¬ 
teresting  to  the  writer,  who  participated  in  many  of  these  analyses. 
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time  one  token  is  removed  from  each  input  place  and  one  token  is  added  to  each  (possibly  many)  output  place.  On 
the  first  cycle  I,  only  r,  is  enabled.  At  2,  transition  is  enabled.  At  3,  is  again  enabled.  At  4,  ^2  enabled,  and 
the  transition  to  5  ends  the  activity.  (From  Telerobotics,  automation,  and  human  supervisory  control  [Fig.  1.33], 
by  T.  Sheridan,  1992,  Cambridge,  MA:  MIT  Press.  Copyright  ©  1992  by  MIT  Press.  Reprinted  with  permission.) 
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was  the  dilTiculty  plant  personnel  had  in  considering  at  each  task  step 
what  inlomiation  the  operator  needed  and  what  process  variahle(s)  had  to 
heeontrolled  hy  what  eriteria.  Many  of  the  analysts  eould  envision  the 
tasks  only  in  terms  of  what  display  and  eontrol  deviees  already  existed, 
so  the  task  analysis  was  eoneeived  in  terms  of  what  operators  looked  at 
and  what  they  manipulated.  The  analysts  often  .seemed  unable  to  eon- 
sider  what  alternative  and  potentially  better  ways  there  might  he  to  dis¬ 
play  the  required  information  and  control  the  salient  variables,  which  of 
course  is  the  basic  purpose  of  task  analysis. 

What  has  clearly  been  happening,  ever  so  quietly  (cynics  might  say 
insidiously)  is  that  computers  have  been  insinuating  themselves  into 
systems:  automobiles,  medical  devices,  industrial  machinery,  home 
appliances,  and  of  course  military  systems.  In  these  systems  the  com¬ 
puters  perform  data  processing  for  sensing,  providing  advice  (expert 
systems  and  decision  aids)  and  decision  making,  in  many  cases  closing 
control  loops  through  arlificial  sensors  and  actuators  without  any  hu¬ 
man  intervention.  This  moves  the  human  to  a  new  role  of  being  a  su¬ 
pervisor  rather  a  direct  or  “inner-loop'*  controller.  As  a  supervisor,  be  or 
she  operates  at  a  higher  level  than  in  direct  manual  control,  or  in  an 
“outer  kK)p.“  The  supervisor  observes  computer-based  displays  and  gets 
advice  in  the  form  of  integrated  information  rather  than  raw  data;  the 
supervisor  gives  instructions  (goals,  constraints,  procedure.s,  sugges¬ 
tions)  in  high-level  (more  human)  language  to  a  relatively  intelligent 
machine  capable  of  understanding  more  complex  strings  of  if-thcn-cisc 
instructions  and  implementing  them  in  the  physical  world.  The  use  of 
the  “llight  management  computer  .system”  in  a  modern  commercial 
aircraft  is  a  good  example,  but  one  can  cite  other  examples  in  a  variety 
of  systems  from  hospitals  to  chemical  plants  to  undersea  and  space  ro¬ 
bots.  Sheridan  (1992)  provides  detailed  examples  and  theoretical  discus¬ 
sion  of  supervisory  control. 

Figure  1.3  considers  systems  of  various  levels  of  automation  per¬ 
forming  tasks  of  various  degrees  of  complexity  (entropy  or  unpredict¬ 
ability),  and  indicates  how  some  of  these  are  undesirable  (e.g.,  menial 
labor,  in  the  lower  left  corner)  and  some  arc  currently  not  possible  (e.g., 
ultimate  robot,  in  the  upper  right  corner).  The  upper  left  and  lower  right 
corners  offer  .satisfactory  solutions.  Supervisory  control  is  seen  as  a 
range  of  technology -enabled  options  progressing  gradually  from  lower 
left  to  upper  right.  Several  examples  arc  given. 

The  roles  (categories  of  functions)  of  the  supervisor  may  he 
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Figure  1 .3.  Systems  oF  various  levels  oF  automation  performing 
tasks  oF  various  degrees  ol'  complexity  (entropy  or  unpredictability). 
(From  Tele  robotics,  automation,  and  human  supervisory  control  [Fig. 
4.1],  by  T.  Sheridan,  1992,  Cambridge,  MA:  MIT  Prc.ss.  Copyright  © 
1992  by  MIT  Press.  Reprinted  with  permission.) 


considered  to  be:  (1 )  planning,  usually  done  off-line,  with  the  aid  of  the 
computer  and  displays  in  a  simulation  mode;  (2)  teaching 
(programming)  the  computer  with  appropriate  goals,  constraints,  proce¬ 
dures,  and  suggestions;  (3)  putting  the  system  (or  parts  of  the  system) 
into  automatic  mode  when  ready  and  monitoring  its  operation  for  ab¬ 
normalities;  (4)  intervening  in  the  ease  of  perceived  abnormalities  to 
diagno.se  failures,  reprogram  to  alternate  automatic  control  modes,  per- 
I'orm  direct  manual  control,  or  abort  the  mission,  as  appropriate;  and  (5) 
learning  From  experience,  so  as  to  improve  the  planning  for  future  op¬ 
erations.  Thc.se  roles  arc  seen  in  Figure  1.4  to  be  nested  at  three  levels, 
the  monitoring  taking  place  in  a  tight  feedback  loop,  the  intervention 
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Figure  1 .4.  Roles  of  the  supervisor.  (From  Telerobotics,  automa¬ 
tion,  and  human  supervisory  control  [Fig.  1.2],  by  T.  Sheridan,  1992, 
Cambridge,  MA:  MIT  Press.  Copyright  ©  1992  by  MIT  Press.  Re¬ 
printed  with  permission.) 
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Table  1.2.  Detailed  breakdown  of  supervisory  roles 


SUPERVISORY  STEP 

ASSOCIATED 

MENTAL  MODEL 

ASSOCIATED 
COMPUTER  AID 

— 

—►1.  PLAN 

1  a)  understand 

controlled  process 

physical  variables: 
transfer  relations 

physical  process 
training  aid 

1 

b)  satisfice  objectives 

1 

aspirations;  preferences 
and  indifferences 

satisficing  aid 

c)  set  general  strategy 

general  operating 
procedures  and  guidelines 

procedures  training 
and  optimization  aid 

1 

— ►2.  TEACH 

1 

1 

a)  decide  and  test 
control  actions 

decision  options: 

St  ate-procedure^act  ion 
implications:  expected 
results  of  control  actions 

procedures  library: 
action  decision  aid 
(in-situ  simulation) 

1 

b)  decide,  test,  and 

comrrxjnicate  commands 

commarHl  language 
(symbols,  syntax,  semantics) 

aid  for  editing 
commands 

1 

3.  MONITOR  AUTOMATION 

1 

1 

a)  acquire,  calibrate,  and 
combine  measures 
of  process  state 

state  information  sources 
and  their  relevance 

aid  for  calibration 
and  combination 
of  measures 

1 

b)  estimate  process  state 
from  current  measure 
and  past  control  actions 

expected  results  ot  past 
actions 

estimation  aid 

1 

1 

c)  evaluate  process  state: 
detect  and  diagnose 
failure  or  halt 

Nkely  nx)des  and  causes 
of  failure  or  halt 

detection  and  diagnosis 
aid  for  failure  or  halt 

1 

4.  INTERVENE 

1 

a)  it  failure:  execute 
planned  abort  — j 

criteria  and  options 
for  abort 

abort  execution  aid 

1 

1 

b)  if  error  benign: 

act  to  rectify  j 

criteria  for  error  arxl 
optKXis  to  rectify 

error  rectification  aid 

1 

c)  if  norrr^l  end  of  i 

task:  complete  I 

optior^  arni  cnteria 
for  task  completion 

normal  completion 
execution  aid 

,  ^  ^ 

1  5.  LEARN 

I  a)  record  immediate 

events 

immediate  memory 
of  salient  events 

immediate  record 
and  memory  jogger 

1 

U- 

b)  analyze  cumulative 

experience,  update  model 

cumulative  merTX>ry 
of  salient  events 

cumulative  record 
arrd  analysis 

Source:  From  Telerobotics,  automation,  oful  human  supervisory  control  (Fig. 
1.41),  by  T.  Sheridan,  1992,  Cambridge,  MA:  MIT  Press.  Copyright  ©  1992  by 
MIT  Press.  Reprinted  with  permission. 
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leading  to  reprogramming,  and  the  learning  resulting  in  improved  plan¬ 
ning.  Table  1.2  breaks  these  functions  into  greater  detail. 

In  Table  1 .3,  a  ten-point  scale  of  degrees  of  eomputer  involvement  is 
presented,  as  proposed  by  Sheridan  and  Verplank  (1978).  From  eonsider- 
ing  this  scale,  it  is  clear  that  the  amount  of  automation  raises  some 
serious  questions. 

CURRENT  POPULAR  RESEARCH  TOPICS 
THAT  IMPACT  FUNCTION  ALLOCATION 

The  following  arc  some  popular  topics  that  seem  particularly  closely 
related  to  human-machine  function  allocation. 

ATTENTION  ALLOCATION  AND 
MENTAL  WORKLOAD 

Mental  workload  has  been  a  popular  topic  for  more  than  a  decade,  but 
the  interest  today  is  largely  in  the  problem  of  workload  transients  (Huey 


Table  L3.  Scale  of  degrees  of  eomputer  aiding 

ll  is  possible  for  system  hardware  and/or  software  to  provide  any  of  the  options 
shown  below  (ANDed  or  ORed  as  noted); 

1.  Offer  no  assistance  to  the  operator. 

2.  Offer  a  eompletc  set  of  alternatives  to  the  operator,  AND 
3  narrow  the  set  of  alternatives  to  a  restrieted  set,  OR 

4.  suggest  one  of  the  alternatives,  AND 

5.  execute  the  suggestion  if  the  human  approves,  OR 

6  allow  the  human  to  veto  the  suggestion  before  automatic  execution,  OR 

7.  inform  the  human  after  execution,  OR 

8.  inform  the  human  after  execution,  if  asked,  OR 

9.  inform  the  human  after  execution,  if  the  hardware  and  software  decide  to. 

10  Decide  everything  without  communication  to  the  human 


Source:  After  Sheridan  (1992). 
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&  Wickcns,  1993).  Workload  transients  occur  when  automatic  or  semi¬ 
automatic  systems  go  awry  or  fail  to  control  unexpected  events,  and  the 
human  monitor  or  supervisor  has  a  difficult  time  diagnosing  the  prob¬ 
lem  and  taking  proper  action.  In  such  cases,  the  workload  changes  sud¬ 
denly  from  very  low  to  very  high.  Measurement  of  these  transients  is 
particularly  difficult,  because  most  physiological  and  secondary-task 
techniques  require  sampling  over  a  time  period  of  minutes.  Subjective 
scaling  also  becomes  awkward  when  things  are  changing  rapidly. 

The  need  is  to  smooth  out  the  pace  by  anticipating  times  of  high 
workload  and  getting  things  set  up  early,  for  example,  in  getting  ready 
for  let-down  and  approach  in  landing  an  aircraft.  Pilots  call  it  “keeping 
ahead  of  the  airplane.”  In  emergencies,  nuclear  power  plant  operators 
take  actions  Just  to  buy  time  and  allow  themselves  a  longer  period  to 
perform  diagnoses  and  insure  that  their  response  is  appropriate. 

Tulga  (Tulga  &  Sheridan,  1980)  simulated  and  modeled  such  a  situa¬ 
tion  with  a  paradigm  similar  to  that  shown  in  Figure  1.5,  where  ran¬ 
dom  blocks  (representing  tasks)  appeared  on  a  computer  screen  at  differ¬ 
ent  distances  from  a  vertical  “deadline”  on  the  right  and  moved  at 
constant  velocity  toward  it.  The  duration  of  the  task  was  the  block's 
width;  its  relative  importance,  the  reward  per  unit  time  for  doing  it  (by 
various  means  such  as  holding  a  cursor  on  it),  was  the  block's  height. 
Tulga  found  that  subjects  in  this  task  were  objective  and  even  near  to 
optimal  in  their  attention  and  effort  allocation — up  to  a  point  of  high 
workload.  Then  they  simply  paid  attention  to  what  was  nearest  to  the 
deadline,  regardless  of  relative  importance. 

A  related  problem  of  particular  interest  is  the  nesting  of  stimulus  and 
required  response,  where  first  notice  of  a  required  action,  say  A,  is 
shortly  followed  by  notice  of  required  action  B,  where  the  deadline  for  B 
comes  sooner  than  that  for  A.  If  the  operator  is  not  sufficiently  re¬ 
minded  of  A,  the  result  is  often  that  B  is  taken  care  of,  but  A  is  forgot¬ 
ten.  Such  nesting  can  sometimes  be  several  layers  deep,  with  disastrous 
results. 

SITUATION  AWARENESS 

There  is  currently  great  interest  in  “situation  awareness,”  the  ability 
of  the  operator  to  keep  track  of  many  things  at  once,  to  integrate  them, 
and  to  diagnose  when  events  are  turning  abnormal  or  threatening.  It  is  a 
problem  exacerbated  by  automation,  though  possibly  a  problem  that 


duration  of  attention 
required  to  complete 
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and  human  supervisory  control  [Fig.  1.32],  by  T.  Sheridan,  1992,  Cambridge,  MA:  MIT  Press.  Copyright  ©  1992 
by  MIT  Press.  Reprinted  with  permission.) 
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can  be  helped  by  computers — in  the  form  ol  “expert  systems,”  decision 
aids,  and  reminders — to  direet  the  operator’s  attention  while  monitoring. 
Failure  to  remain  situationally  aware  has  resulted  in  many  kinds  of  er¬ 
rors,  most  salient  among  them  mtxle  errors,  where  operators  forget  what 
mode  some  automatie  system  has  been  placed  into.  In  a  well-known 
Airbus  aecident  near  Strasbourg,  the  pilot  interpreted  numbers  on  the 
computer  display  to  mean  one  thing  when  they  meant  something  en¬ 
tirely  different;  the  pilot  had  forgotten  the  mode  into  which  he  had  set 
the  aircraft. 

Experience  in  any  type  of  human  task  results  in  behavior  that  be¬ 
comes  automatic  and  that  docs  not  require  as  much  conscious  delibera¬ 
tion  as  during  initial  learning.  One  might  conclude  that  this  gives  the 
operator  more  time  to  scan  and  be  aware  of  the  surrounding  situation, 
hut  by  the  same  token  such  “downloading”  of  task  elements  and  lowered 
self-consciousness  can  result  in  situation  unawarcncss. 

HUMANS’  AND  COMPUTERS’  RUNNING  MODELS 
OF  EACH  OTHER 

Mental  models  have  been  a  popular  topic  in  cognitive  psychology  for 
a  decade.  The  term  mental  model  usually  means  some  mental  represen¬ 
tation  of  objects  in  the  external  world  associated  with  a  task  that  can  be 
run  dynamically  to  predict  what  will  happen  if  current  conditions  arc 
extrapolated,  or  what  would  happen  if  certain  hypothetical  changes  took 
place.  There  have  been  complaints  that,  while  hardware — for  example, 
the  trajectory  of  an  observed  vehicle — is  relatively  transparent,  the  fu¬ 
ture  action  of  a  computer  is  not — the  computer  is  a  black  box,  and  not 
transparent.  For  this  reason,  some  have  suggested  that  it  is  important 
that  the  computer  inform  its  human  operators  about  what  it  understands 
and  what  it  therefore  intends  to  do. 

While  the  need  for  human  communication  with  and  modelling  of  the 
computer  seems  obvious,  the  need  for  the  computer  to  have  some  repre¬ 
sentation  or  model  of  the  human  appears  less  obvious.  However,  were 
the  computer  able  unobtrusively  to  find  out  and  keep  track  of  the  opera¬ 
tor's  intentions,  preferences,  training,  stress,  and  physical  limitations, 
especially  in  times  of  the  human’s  absence  or  illness,  it  might  be  able 
to  make  more  intelligent  decisions,  much  as  would  a  human  colleague. 
Figure  1 .6  suggests  the  notion  that  the  human  and  the  computer  keep 
running  models  of  one  another. 


Figure  1.6.  People  and  machines  have  models  of  each  other. 
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ALIENATION  FROM  COMPUTERS 
AND  AUTOMATION 

Computers  make  problems  Tor  human  operators  not  only  lunctionally 
but  in  other  ways  as  wcIL  particularly  when  intrtxluccd  abruptly  and 
when  the  operator  has  little  say  in  how  and  why  the  change  occurred. 
Problems  include:  isolation  from  soeial  contact,  worry  about  employ¬ 
ment,  loss  of  skill  and  the  associated  dignity,  intimidation  of  ‘‘hig 
brother  watching,”  feelings  of  ignorance  and  helplessness,  reduced  trust 
in  the  situation,  and  reduced  sense  of  responsibility — all  of  which 
clearly  diminish  the  ability  to  function.  Any  of  these  factors,  particu¬ 
larly  loss  of  trust,  can  reduce  the  operator's  willingness  to  make  use  of 
computer-based  sensing,  advising,  and  automation  modes  that  rationally 
could  be  to  great  advantage  (Moray  &  Lee,  1 990). 

CANONICAL  THEORIES  OF  MANAGEMENT 
APPLIED  TO  TEAMS 

Allocating  functions  among  the  members  of  a  team  is  a  form  of 
management  (whether  hidden  in  the  system  design  or  not),  and  .so  it  is 
important  to  be  aware  of  the  various  theories  of  management.  An  earlier 
view,  variously  referred  to  as  “scicniillc  management”  or  “theory  X,” 
was  attributed  to  F.  L.  Taylor.  Now  definitely  out  of  favor  among  in¬ 
dustrial  engineers,  it  considered  the  human  to  be  a  machine  and  sought 
to  define  and  measure  performance  quantitatively.  Of  course,  that  is 
precisely  what  the  human-machine  systems  approach  seeks  to  do,  but 
perhaps  with  some  better  appreciation  of  the  humanistic  character  of  the 
worker  or  operator. 

Another  theory,  attributed  to  A.  Maslow  and  F.  Hertzberg  and  called 
“theory  Y,”  begins  from  the  assumption  that  any  worker  works  for  per¬ 
sonal  rewards  and  satisfaction,  and  that  good  management  amounts  to 
enabling  and  empowering  workers,  and  motivating  them  to  develop 
individual  initiative  and  potential.  A  scientific  function  allocation  has  a 
.somewhat  more  dilTicult  time  with  this  perspective  and  may  merely 
regard  it  as  unrelated  or  irrelevant,  possibly  leading  to  job  allocations 
that  seem  rationally  correct  hut  arc  not  satisfying  and  rewarding  to  the 
workers,  with  unhappy  results. 

The  more  recently  popular  “theory  Z,”  attributed  to  W.  Ouchi  and  E. 
Deming,  calls  for  development  of  consensus — including  function 
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Series 


P  (series  combination  succeeds)  = 

P  (both  m  and  h  succeed)  = 

[1  -P(m))«[1  -  P(h))  if  h  failure  independent  of  m , 

[1-  P(m))*(1-  P(h|m  succeeds))  if  h  failure  dependent  on  m 


P(parallel  combination  succeeds)  = 
P(either  or  both  m  or  h  succeed)  = 
1-  P(both  m  and  h  fail)  = 


1  -  P(m)*P(h)  if  h  failure  independent  of  m, 

1  -  P(m)«P(h|m  fails)  if  h  failure  dependent  on  m 


Figure  1.7.  Reliability  of  functional  elements  in  series  and  in  paral¬ 
lel,  where  P(x)  =  P(x  fails). 
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allocation  and  reallocation — through  shared  goals  and  values,  quality 
circles,  and  “total  quality  management,”  This  approach  militates  against 
dc.signing  rigid  systems  by  a  priori  function  allocation  and  favors  allow¬ 
ing  enough  flexibility  so  that  allocation  can  always  be  refined  by  con¬ 
tinued  operator  participation  in  problem  solving  and  process  improve¬ 
ment. 

HUMAN-MACHINE  SYSTEM  ARCHITECTURES 

With  consideration  of  all  of  the  above  factors,  the  system  engineer 
must  return  to  the  problem  of  architecture  for  the  human-machine  sys¬ 
tem,  the  question  of  how  all  the  elements  fit  together  and  perform,  and 
the  implications  of  different  function  allocations  for  system  perform¬ 
ance. 

Here,  finally,  we  must  decide  whether,  and  for  which  functions,  hu¬ 
man  and  machine  cooperate  by  “trading”  or  by  “sharing.”  In  trading 
back  and  forth,  the  human  acts  and  then  the  machine  acts.  In  sharing, 
the  human  and  the  machine  work  in  parallel;  either  both  redundantly 
perform  the  same  job  and  these  results  are  later  compared  as  a  check,  or 
each  docs  part  of  the  Job  and  the  pieces  arc  brought  together  in  hopes 
they  will  fit.  The  reliability  analyst  sees  these  alternatives  in  terms  of 
whether  the  elements,  be  they  human  or  machine,  operate  in  series  or  in 
parallel,  and  what  the  reliability  implications  arc  (Figure  1,7).  Perhaps 
the  simplest  notion  is  that  various  intelligent  (human  or  computer- 
based  automatic)  agents  arc  given  freedom  to  perform  their  assigned 
functions  as  they  will,  and  only  when  their  behaviors  conflict  docs  the 
.supervisor  step  in,  inhibit  one  (or  more  as  necessary)  and  enable  the 
others  to  go  ahead.  This  approach,  called  by  Brooks  (1986)  a  “sub¬ 
sumption  architecture,”  was  shown  by  him  to  work  for  simple  robots, 
but  it  broke  down  for  systems  faced  with  more  sophisticated  problems. 

Ultimately,  the  function  analyst  must  face  the  question  of  which  has 
authority  under  what  circumstances,  human  or  machine.  It  is  comfort¬ 
ing  for  us  to  assert  that  the  human  always  has  final  authority,  but,  at 
the  same  time,  we  readily  submit  to  getting  into  elevators  and  pushing 
their  buttons,  thus  turning  authority  over  to  those  machines,  or  .spend¬ 
ing  the  night  in  high-rise  hotels,  trusting  completely  to  the  premise 
that  strong  winds  won’t  blow  them  over.  Figure  1.8  suggests  ,somc 
categories  of  programmed  ultimate  authority  as  a  function  of  level  of 
abnormality. 
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WHY  FUNCTION  ALLOCATION 
AND  WHY  NOW? 

J.  R,  Bost  and  F.  R.  Oberman 


Function  allocation  is  necessary  to  optimize  the  use  of  hu¬ 
man,  hardware,  and/or  software  capabilities  in  advanced 
systems.  A  variety  of  methods  have  been  developed  for  func¬ 
tion  allocation,  each  responding  to  the  constraints  of  other 
methods.  At  the  .same  time,  developments  in  automation  are 
causing  ever  more  functions  to  be  allocated  to  machines.  This 
can  provide  significant  cost  benefits  in  systems  such  as  ships, 
where  major  reductions  can  be  made  in  personnel  levels  and, 
in  some  cases,  in  hunuut  errors.  However,  the  trend  to  in¬ 
creased  automation  poses  several  questions  for  which  re¬ 
search  is  needed,  including:  user  trust  in  highly  automated 
systems:  the  role  of  the  human  in  future  systems;  dynamic 
function  allocation;  and  the  relationship  between  the  com¬ 
puter  and  the  human.  Current  approaches  to  systems  engi¬ 
neering  do  not  emphasize  function  allocation  to  personnel 
and/or  hardware  or  software,  but,  rather,  concentrate  on 
subfunction  assignment.  It  is  suggested  that  a  function  alloca¬ 
tion  approach  could  he  included  as  part  of  a  situational  as¬ 
sessment  management  process,  which  may  include  group 
problem  solving,  for  formulating  solutions  to  complex  prob¬ 
lems. 


INTRODUCTION 

Function  allocation  is  the  Urst  systems  engineering  process  that  it\- 
dresses  functions  in  terms  of  personnel.  A  comprehensive  and  measur¬ 
able  function  alkKation  prcK’c.ss  is  needed  now  to  ensure  optimal  use  of 
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Table  2.1.  Common  form  of  Fitts'  List 


PEOPLE  EXCEL  IN 

MACHINES  EXCEL  IN 

Detection  of  certain  fonns 
of  very  low  energy  levels 

Monitoring  (both  human 
and  machines) 

Sensitivity  to  an  extremely  wide 
variety  of  stimuli 

Performing  routine,  repetitive,  or 
very  precise  operations 

Perceiving  patterns  and  making 
generalizations  about  them 

Responding  very  quickly  to  con¬ 
trol  signals 

Ability  to  store  large  amounts  of 
information  for  long  periods,  and 
recall  relevant  facts  at  appropriate 
moments 

Storing  and  recalling  large 
amounts  of  information  in  short 
time  periods 

Ability  to  exercise  judgment 
where  events  cannot  be  com¬ 
pletely  predicted 

Performing  complex  and  rapid 
computation  with  high  accuracy 

Improving  and  adopting  flexible 
procedures 

Sensitivity  to  stimuli  beyond  the 
range  of  human  sensitivity 
(infrared,  radio  waves,  etc.) 

Ability  to  react  to  unexpected 
low-probability  events 

Doing  many  different  things  at 
one  time 

Applying  originality  in  solving 
problems:  i.e.,  alternative  solu¬ 
tions 

Exerting  large  amounts  of  force 
smoothly  and  precisely 

Ability  to  profit  from  experience 
and  alter  course  of  action 

Insensitivity  to  extraneous  fac¬ 
tors 

Ability  to  perform  fine  manipu¬ 
lation,  especially  where  mis¬ 
alignment  appears  unexpectedly 

Ability  to  repeat  operations  very 
rapidly,  continuously,  and  pre¬ 
cisely  the  same  way  over  a  long 
period 

Ability  to  continue  to  i^erform 
when  overloaded 

Operating  in  environments 
which  are  hostile  to  humans  or 
beyond  human  tolerance 

Ability  to  reason  inductively 

Deductive  processes 

Source:  US  Department  of  Defense  (1987). 


Why  Function  Allocation  and  Why  Now 


31 


advanced  automation  technology  and  an  optimal  role  for  the  human  in 
future  systems. 

Criteria  for  formal  function  allocation  were  initially  developed  hy 
Paul  Fitts  at  Ohio  State  University  in  1951.  The  original  Fitts'  List 
compared  the  capabilities  of  human  and  machine.  Fitts'  view  was  that, 
hy  applying  these  criteria,  an  optimum  al legation  of  functions  between 
humans  and  machines  could  he  achieved. 

As  shown  in  the  figure  in  the  Executive  Summary,  these  human- 
machine  allocations  provide  the  baseline  for  subsequent  efforts  relating 
to  control/display  task  requirements,  workplace  configuration  require¬ 
ments,  workload  requirements,  and  workstation  design  and  development. 
In  addition,  function  allocation  dictates  crew  workload  and  the  role  of 
the  human,  thereby  significantly  dcllning  human  resource  levels,  train¬ 
ing,  and  procedure  requirements  (Dost,  Miller,  &  Finney,  1986). 

A  common  form  of  the  Fitts'  List  used  by  the  US  Department  of 
Defense  (1987)  is  shown  in  Table  2.1.  This  format  again  emphasized 
direct  comparison  o( capabilities,  which  were  then  applied  sequentially 
against  dcllncd  system  functions.  Other  versions  of  Fitts'  List  not  only 
compare  the  capabilities  of  humans  and  machines  hut  also  the  limita¬ 
tions  of  humans  and  machines. 

ISSUES  AND  ALTERNATIVES 

Function  alkx:ation  criteria  have  continued  to  he  developed  and  im¬ 
proved  in  response  to  problems  with  (1)  sequential  dichotomous  appli¬ 
cations  of  Fitts'  lists  (or  the  sequential  selection  of  human  or  machine 
based  on  single  capabilities  or  limitations);  (2)  assessments  of  human 
machine;  (3)  the  qualitative  nature  of  assignments;  and  (4)  political, 
managerial,  llnancial,  and  pcrfomiancc  constraints.  The  problem  of  se¬ 
quential  dichotomous  application  has  been  addressed  hy  Price  (1985), 
who  proposed  six  different  categories  or  regions  of  human-machine  per¬ 
formance  as  shown  in  Figure  2.1. 

The  problem  of  human  computer  allocation  has  been  addressed  by 
Sheridan  (Table  1.3).  More  recently,  Malone,  Baker,  and  Obennan 
(1992)  dealt  with  this  issue  hy  restating  the  allocation  process  to  define 
the  role  of  the  human  in  using  the  system.  This  approach  could  be  ex¬ 
tended  to  define  the  role  of  the  human  in  the  design  of  the  system.  The 
qualitative  nature  of  assignments  and  the  need  for  more  sophisticated 
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Figure  2.1.  Criteria  for  allocating  functions  to  human  or  machine.  (From  Beevis,  1992,  Fig.  3.2;  after 
Price,  1985.) 
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criteria  have  been  addressed  hy  Beevis  (1992)  and  by  Sheridan  (1994). 

Kantowilz  and  Sorkin  (1987)  developed  a  balanced  approach  to  deal 
with  political  and  managerial  constraints,  as  well  as  pcrfonnance  eon- 
.straints.  Mcistcr  (1985)  has  also  developed  a  live-stage  balanced  ap¬ 
proach,  as  shown  in  Figure  2.2. 

Another  view  ol  function  allocation  is  found  in  the  approaches  enu¬ 
merated  hy  R.  W.  Bailey  (1982).  Bailey  categorizes  three  approaches  to 
function  allocation: 

•  a  comparison  of  the  relative  capabilities  of  humans  and  machines; 

•  the  automation  of  as  many  functions  as  technology  permits,  with 
only  the  leftover  functions  being  assigned  to  the  human  operator; 

•  the  use  of  economic  allocation  methods  to  emphasize  cost  con¬ 
straints  as  a  basis  for  the  allocation. 

The  future  of  function  allcKation  probably  will  be  oriented  toward  a 
synthesis  of  the  balanced  approach  and  Bailey's  three  approaches,  and  in 
fact  there  can  be  synergistic  bene  fits  generated  by  thc.se  multiple  objec¬ 
tive  approaches.  The  hest  alternative  as  detennined  from  a  traditional 
comparison  may  also  produce  the  best  economic  benefits.  One  approach 
to  ensuring  that  function  al legation  is  performed  in  a  logical  manner 
and  prixluccs  the  best  economic  benefit  (long-term  and  short-term  bcnc- 
llts  should  be  determined  separately)  is  to  do  a  sequential  function  allo¬ 
cation  study;  first  a  traditional  study  is  performed,  then  an  economic 
.study  comparing  drivers  and  benefits  is  conducted  using  a  dcci- 
sion/.sensitivity  analysis  prcK'css. 

COST  BENEFITS 

The  explosion  of  information  is  leading  toward  the  allocation  ol*  more 
functions  to  automation.  The  automation  of  functions  will  prcxluce  two 
major  cost  hcnellts:  the  reduction  of  direct  personnel  and  personnel  sup¬ 
port  costs,  and  the  potential  reduction  of  human  error.  Enormous  s;iv- 
ings  potentially  can  be  achieved  in  the  area  of  personnel  reduction. 
Within  the  US  Navy,  personnel  costs  arc  up  to  50  percent  of  life -cycle 
costs,  depending  on  the  cla.ss  of  ship  involved.  Bost,  Mcliis,  and  Dent 
(1994)  believe  that  cultural  changes  in  the  way  we  design,  accjuire,  luid 
operate  ships  will  he  needed  to  bring  about  revolutionary  reduction  in 
ship  personnel  levels.  More  logical,  cost-elTective  fund  ion  allcKation 
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tools  are  required  to  engineer  the  savings  from  personnel  reductions.  A 
key  factor  in  this  process  is  the  recognition  of  the  enormous  cost  of 
keeping  personnel  aboard  the  ship  and  the  importance  of  upgrading  sys¬ 
tem  automation  and  reliability  in  order  to  keep  pace  with  and  use  ad¬ 
vanced  technology.  Personnel  costs  in  the  US  Navy  also  have  a  ship 
acquisition  cost  component,  since  every  person  aboard  ship  requires  an 
associated  supportability  component  of  3-5  tons  of  ship  displacement. 

Another  significant  cost-reduction  factor  in  automating  functions  is 
in  the  reduction  of  human  error,  since  over  50  percent  of  mishaps  are 
now  classified  as  due  to  human  error. 

DEGREE  OF  TRUST  IN  AUTOMATION 

One  of  the  key  cultural  changes  that  will  have  to  take  place  to  secure 
the  personnel  and  accident-reduction  benefits  associated  with  automation 
is  a  change  in  pK)licies,  procedures,  doctrine,  and  perceptions  with  re¬ 
spect  to  trusting  in  automation.  A  first  step  is  to  produce  automated 
equipment  of  sufficient  reliability  to  engender  trust  on  the  part  of  the 
user.  One  discussion  session  at  the  First  Automation  Technology  and 
Human  Performance  Conference  produced  an  interesting  analogy:  in  the 
movie  Star  Trek — The  Next  Generation,  the  android  DATA  is  both 
perceived  and  treated  as  a  member  of  the  crew.  That  type  of  perceptual 
change  must  occur  with  respect  to  automated  verses  manual  functions; 
that  is,  there  must  be  enough  trust  in  the  built-in  reliability  and  per¬ 
formance  of  the  automatic  system  to  allow  it  to  perform  ship  opera¬ 
tions  and  missions.  This  will  have  profound  and  significant  changes  on 
doctrine  and  procedures,  on  the  role  of  the  human,  and  on  the  redefini¬ 
tion  of  resjxjnsibility. 

On  the  other  hand,  humans  must  not  become  so  complacent  in  using 
automation  that  normal  monitoring  does  not  take  place.  The  recent 
Aeroflot  Airbus  crash  in  which  the  pilot,  who  was  found  in  the  passen¬ 
ger  compartment,  left  his  son  (who  managed  to  disengage  the  autopilot) 
in  the  cockpit,  is  an  example  of  poor  judgement  engendered  by  compla¬ 
cency  with  respect  to  the  automatic  pilot. 

The  answer  is  that  the  general  situation  should  determine  the  degree 
of  automation;  for  example,  chemical  process  control  already  has  high 
degrees  of  automation.  Yet  in  cases  that  are  not  time  dependent,  the 
human  will  still  play  the  major  role  of  decision  maker/monitor. 


36 


Improving  Function  Allocation 


AUTOMATION  TODAY 

One  of  the  reasons  automation  is  able  to  provide  these  cost  benefits 
is  the  current  state  of  the  art  and  expected  near-future  development  in 
this  technology.  Automation  has  advanced  a  long  way  since  Fitts'  ini¬ 
tial  concept  was  developed — a  PC  is  now  more  powerful  and  faster  than 
a  main  frame  in  1951.  Not  only  has  the  technology  changed  to  allow 
the  implementation  of  reduced-manning  concepts  that  were  only  advo¬ 
cated  in  the  1950s  and  1960s,  but  a  new  generation  of  computer-literate 
personnel  will  very  shortly  be  available  to  implement  the  decisions  and 
actions  of  the  future.  They  will  think  in  terms  of  the  computer  to  ac¬ 
complish  these  ends. 

Not  only  has  automation  technology  enhanced  the  speed  and  perform¬ 
ance  of  functions,  it  has  also  provided  the  same  benefits  to  the  devel¬ 
opment  of  human  factors  tools,  including  those  used  for  function  allo¬ 
cation.  Tools  have  been  developed  for  performing  function  allocation 
for  total  system  design  and  for  system  reengineering  (Malone,  1992; 
Chap.  13  by  Swartz  &  Wallace  in  this  volume).  The  capability  to  carry 
out  computer-assisted  function  allocation  can  now  enable  this  human- 
system  engineering  process  to  be  performed  and  the  results  of  the  analy¬ 
ses  used  within  the  time  constraints  of  project  design  phases.  Moreover, 
when  function  allocation  is  performed  in  the  conceptual  phases  of  ac¬ 
quisition,  data  storage  by  electronic  means,  such  as  on  CD-ROM,  al¬ 
lows  the  iterative  updating  of  information  to  proceed  in  a  cost-effective, 
timely  manner. 


FUTURE  RESEARCH  QUESTIONS 

There  are  questions  that  come  with  the  opportunities  which  will  be 
available  in  implementing  the  function  allocation  methodologies  of  the 
future.  Among  the  most  important  questions  are: 

•  Should  a  review  of  earlier  versions  of  Fitts'  lists  be  undertaken  to 
ensure  that  new  technology  has  not  altered  the  original  compari¬ 
sons? 

•  What  is  the  role  of  humans  to  be  in  future  systems?  Is  the  human 
only  to  be  a  system  monitor,  while  machines  perform  most  func¬ 
tions?  If  so,  how  and  by  what  criteria  do  humans  override  computer 
operations? 
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•  How  does  the  human  decide  when  there  is  an  automation  malfunc¬ 
tion?  How  will  we  ensure  that  systems  will  give  the  human  opera¬ 
tor  adequate  time  both  to  perceive  a  malfunction  and  to  initiate  cor¬ 
rective  action? 

•  If  a  human  is  in  control,  should  the  decision  as  to  when  to  shift  to 
automatic  control  be  standardized  in  doctrine  or  left  open  to  indi¬ 
vidual  judgement?  What  should  be  provided  in  the  way  of  decision 
aids?  Should  we  ever  let  the  system  be  involuntarily  taken  over  by 
automation?  What  would  be  the  criteria  for  allowing  automation  to 
take  control?  Should  the  operator  be  notified  when  automation  has 
taken  control? 

•  Function  allocation  will  become  more  dependent  on  expert 
(opinion)  systems  in  the  future.  What  studies  are  now  taking  place 
with  respect  to  validation  and  evaluation  of  results?  What  criteria 
have  been  established  to  determine  the  value  of  proposed  function 
allocation  tools?  Has  a  consideration  of  return  on  investment  been 
factored  into  current  tool  development? 

•  There  are  cultural  differences  in  how  automation  is  currently  ap¬ 
plied  (Tefler,  1994).  The  European  A320/340  Airbus  is  flown  with 
different  degrees  of  manual  and  automatic  control,  depending  on  the 
country  and  airline  operating  it.  Are  cultural  differences  and  diver¬ 
sity  useful  or  should  the  degree  of  automation  and  the  decision  on 
when  to  use  it  be  controlled  or  standardized? 

•  How  should  the  problem  of  keeping  controllers/decision  makers 
proficient  in  manual  (backup)  operations  be  handled? 

•  Should  automatic  systems  take  over  from  a  human  operator  in  pe¬ 
riods  of  high  workload?  (This  assumes  workload  sensors  will  be  re¬ 
quired.)  When  should  control  be  transferred  back?  Should  this  be  a 
human  decision  or  should  it  be  performed  automatically?  Should 
dynamic  task  automation  (Hilburn  et  al.,  1994)  be  considered? 

•  What  status  information  should  be  displayed  and  how  should  it  be 
displayed?  Should  it  be  under  human  control  or  should  some  status 
information  be  displayed  automatically?  If  it  is  displayed  automati¬ 
cally,  what  should  be  displayed  and  when  should  it  be  displayed? 

•  For  some  new  display  systems,  new  cognitive  skills  and  cognitive 
pathways  are  required.  What  is  being  done  to  ensure  that  overall 
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human-machine  operational  processing  is  improved  with  respect  to 
accuracy  and  time? 

•  How  do  we  evaluate  alternatives?  What  criteria  should  be  used?  Can 
these  criteria  be  further  used  to  generate  deterministic  and/or  prob¬ 
abilistic  performance  parameters?  Can  we  now  evaluate  overall  reli¬ 
ability  of  the  human-machine  system  by  using  decision  analysis 
and  sensitivity  analyses? 

SYSTEMS  ENGINEERING  CONCERNS 

Although  universities  include  human  factors  as  an  essential  compo¬ 
nent  of  systems  engineering  and  include  function  allocation  as  a  funda¬ 
mental  analytical  process,  this  view  of  function  allocation  has  not  been 
incorporated  in  recent  proposed  revisions  to  the  US  military  standard 
MIL-STD-499B,  Systems  Engineering  (US  Dept,  of  Defense,  1994). 
There  seems  to  be  confusion  between  the  two  analytical  processes  of 
requirements  allocation,  which  matches  requirements  against  functions, 
and  function  allocation,  which  matches  functions  against  human- 
machine  capabilities  and  limitations.  Because  of  this  confusion,  no 
attention  has  been  given  to  human-machine  comparisons.  The  need  for 
human-machine  analysis  must  be  reiterated  in  this  primary  systems 
engineering  document. 

FINAL  PARADIGM— SITUATIONAL  MANAGEMENT 

There  has  been  much  discussion  of  situation  awareness  with  respect 
to  decision  making  and  control.  What  is  really  needed  is  to  manage  de¬ 
cision  making  and  control  with  respect  to  two  variables:  available  time 
and  problem  complexity.  Moreover,  problem  solving  should  not  only 
involve  human  and  computer,  it  should  also  involve  humans  and  com¬ 
puters.  This  gives  the  added  benefit  of  group  participation  in  complex 
problem  solving,  a  benefit  that  has  been  documented  since  the  1960s 
(Oberman,  1964)  and  is  a  recurrent  theme  in  aircraft  and  commercial 
ship  management  today  (Foushee  &  Helmreich,  1988).  A  general  view 
of  situational  decision  management  (SDM)  is  shown  in  Figure  2.3. 
Figure  2.4  presents  an  example  of  situational  assessment.  This  man¬ 
agement  model  emphasizes  the  ultimate  decision  making,  by  humans 
and  computers,  to  be  used  when  appropriate  and  still  considers  the 
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Figure  2,4,  Example  of  situational  assessment. 
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paramount  constraint  of  time  as  an  overriding  factor.  Figure  2.4  shows 
a  recommended  approach  based  on  relevant  research.  It  is,  in  effect,  a 
decision  aid.  In  this  model,  time  is  the  first  decision  point.  If  time  is 
short  (critical),  then  action  should  be  allocated  to  the  preprogrammed 
computer  (automation).  If  an  intermediate  time  exists,  the  manager 
should  initiate  the  action  to  be  taken  (which  can  include  activating  a 
computer  response).  If  the  time  available  for  the  decision  is  long,  then 
the  decision  manager  should  first  assess  whether  the  problem  is  simple 
or  complex.  If  the  problem  is  simple,  then  the  manager  should  initiate 
the  action  to  be  taken  (which  again  can  include  activating  a  computer 
response).  If  the  problem  is  complex,  the  manager  should  discuss  and 
evaluate  solutions  with  an  appropriately  chosen  problem-solving  group 
or  team  and  then  initiate  actions  to  be  taken  by  individual  members  of 
the  group  and/or  software. 

SUMMARY 

WHY  DO  FUNCTION  ALLOCATION? 

We  need  to  do  function  allocation  in  order  to  maintain  logical  and 
rational  control  of  the  human-computer  process.  We  need  to  do  function 
allocation  to  ensure  that  the  role  of  the  human  in  future  systems  is  well 
defined  and  well  understood.  We  need  to  do  function  allocation  to  pro¬ 
vide  the  cost  benefits  of  rational  automation  processes. 

WHY  NOW? 

We  need  to  do  and  improve  function  allocation  now  because  we  are  at 
a  technological  crossroads  engendered  by  the  capabilities  of  software  to 
reliably  take  over  processes  previously  performed  by  humans.  We  need 
to  do  and  improve  automated  function  allocation  processes  now  in  order 
to  be  a  part  of  this  automation  and  information  revolution.  We  need  to 
make  sure  that  function  allocation  is  understood  and  set  forth  as  part  of 
systems  engineering  in  key  military  and  commercial  standards  because 
systems  engineering  is  and  will  be  a  major  controller  of  how  future 
automation  is  performed.  Human  systems  engineering  must  remain  a 
major  player  in  the  systems  engineering  process. 
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FUNCTION  ALLOCATION  AND  MANPRINT' 

M.  K.  Goom 


The  Manpower  and  Personnel  Integration  (MANPRINT)  pro¬ 
gram  provides  a  framework  for  applying  function  allocation 
in  the  development  of  modern  defense  systems.  Within  the 
MANPRINT  framework,  the  contractor  s  task  is  to  determine 
which  of  the  feasible  design  solutions  best  matches  the  skills, 
abilities,  aptitudes,  knowledge,  etc.,  of  the  users.  Experience 
in  formulating  a  practical  approach  to  MANPRINT  suggests 
several  guidelines  for  function  allocation.  Function  alloca¬ 
tion  is  found  to  apply  throughout  the  development  cycle 
rather  than  as  a  clearly  identifiable  event.  The  human  char¬ 
acteristics  that  are  normally  cited  in  illustrations  of  function 
allocation  in  human  factors  texts  are  usually  so  general  that 
they  do  not  help  in  a  practical  way.  It  is  often  very'  detailed 
information  on  the  user's  capability'  and  existing  knowledge 
base  that  will  determine  if  the  task  would  be  better  handled 
by  human  or  by  machine.  The  allocation  of  functions  on  the 
basis  of  job  design  and  resulting  workload  appears  to  be  more 
appropriate.  Workload  prediction  tools  that  can  be  used 
early  and  quickly  are  required.  A  short-term  aim  has  been  to 
develop  a  register  to  capture  the  factors  and  the  thinking  that 
goes  into  allocating  tasks  to  either  human  or  machine.  A  long¬ 
term  aim  is  to  produce  a  task  database  that  carries  informa¬ 
tion  on  learning  difficulty,  retention  times,  etc.,  with  links  to 
specific  user  populations. 


^Copyright  British  Aerospace,  pic.  Reprinted  with  permission. 
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INTRODUCTION 

This  paper  seeks  to  link  the  function  allocation  process  to  some  of  the 
lessons  that  have  been  learned  during  the  development  of  the 
MANPRINT  (Manpower  and  Personnel  Integration)  program  within  the 
Dynamics  Division  of  British  Aerospace. 

Function  allocation  has  been  identified  as  the  weakest  technology  in 
the  process  of  integrating  users  into  defense  systems.  This  paper  at¬ 
tempts  to  show  that,  in  the  real  world,  function  allocation  (and 
MANPRINT)  takes  place  throughout  system  development;  it  does  not 
exist  as  a  discrete  entity  and,  because  of  this  pervasive  nature,  does  not 
attract  the  attention  it  should  from  system  designers.  Many  of  the  prac¬ 
tical  considerations  relate  to  the  constraints  on  time  and  funding  that 
often  accompany  the  commercial  development  of  a  defense  system. 
These  constraints  cause  a  focusing  of  effort  on  those  aspects  that  can  be 
shown  to  have  a  cost  benefit,  are  likely  to  produce  results  in  the  correct 
time  frame,  and,  most  importantly,  can  be  defined  clearly  enough  to 
appear  in  a  work  breakdown  structure  (WBS),  An  additional  practical 
consideration  is  the  problem  of  obtaining  an  adequate  definition  of  the 
end  users  from  the  customer. 

The  traditional  Fitts'  List  approach  to  function  allocation  taught  in 
many  human  factors  courses  is  hardly  sufficient  for  complex  weapon 
systems.  Ergonomists  must  recognize  these  practical  difficulties  and 
devise  methods  that  are  relevant  to  modem  needs  and  can  be  applied 
throughout  the  development  process.  MANPRINT  has  the  same  aims 
as  function  allocation  in  that  it  seeks  to  recognize  the  characteristics  and 
capabilities  of  the  constituent  components  of  the  system.  MAN- 
PRINT’s  strength  is  the  concern  it  focuses  on  the  detail  of  the  end  user. 
The  practical  methodology  British  Aerospace  has  produced  in  response 
to  the  MANPRINT  requirement  provides  useful  indicators  for  the  func¬ 
tion  allocation  activity. 

This  paper  does  not  cover  the  very  interesting  and  important  areas  of 
allocation  between  teams  of  individuals  and  machines  (Stammers  & 
Hallam,  1985).  In  the  next  section,  the  MANPRINT  program  is  briefly 
described  to  identify  the  contractor's  tasks  within  system  development. 
This  section  also  discusses  where  the  allocation  activities  occur  within 
the  system  design  life  cycle.  The  third  section  examines  the  commercial 
constraints  on  projects  that  may  compromise  the  optimal  allocation  of 
functions  among  hardware,  software,  and  the  users.  The  difficulty  that 
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many  system  developers  have  in  separating  mission  analysis,  functional 
analysis,  and  task  analysis  is  considered  in  the  fourth  section.  This  un¬ 
certainty  with  terminology  only  increases  the  problem  of  applying 
function  allocation.  The  fifth  section  considers  the  allocation  process 
itself,  examines  where  the  weaknesses  of  the  traditional  methods  occur, 
and  describes  a  possible  approach  that  has  resulted  from  producing  a 
practical  MANPRINT  implementation.  The  use  of  adaptive  or  dynamic 
function  allocation  and  some  of  the  benefits  and  concerns  are  briefly 
examined  in  the  sixth  section.  The  seventh  section  contains  the  author’s 
suggestions  for  next  steps  to  improve  the  allocation  of  functions  during 
practical  system  development.  Finally,  the  last  section  draws  some  con¬ 
clusions  as  to  why  function  allocation  is  difficult  to  identify  in  a  practi¬ 
cal  development  project  and  suggests  p>ossible  ways  it  eould  be  made 
more  efficient. 


THE  MANPRINT  PROGRAM 

MANPRINT  is  an  acronym  for  manpower  and  personnel  integration 
(Booher,  1990).  Essentially,  it  means  ensuring  that  the  design  is  opti¬ 
mized  for  the  people  who  will  have  to  operate,  maintain,  and  support 
the  hardware  and  software  portions  of  the  system.  MANPRINT  or  hu¬ 
man-systems  integration  or  human  factors  integration  program  or  live¬ 
ware  are  about  designing  for  the  true  end  users.  For  these  reasons,  the 
allocation  of  functions  and  tasks  to  cither  human  or  equipment  is  at  the 
very  core  of  MANPRINT. 

THE  HISTORICAL  REASONS  FOR  MANPRINT 

The  US  MANPRINT  program  came  into  being  during  the  early 
1980s.  It  was  bom  out  of  a  realization  that  many  of  the  high-tech  sys¬ 
tems  that  were  being  delivered  were  not  performing  as  designed.  The 
development  emphasis  had  been  on  the  technology,  with  the  implicit 
assumption  that  suitable  people  could  be  recruited  or  trained,  which 
turned  out  not  to  be  true. 

Complex  systems  were  supposedly  simplified  by  the  use  of  automa¬ 
tion.  Those  functions  that  could  easily  be  automated  became  the  prov¬ 
ince  of  the  machine,  with  little  thought  that  the  remaining  functions  did 
not  constitute  logical  “Jobs”  for  the  users.  Indiscriminate  automation 
often  masks  the  underlying  structure  of  the  system  from  the  users,  caus- 
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ing  learning  difficulties  and  poor  performance.  Function  allocation  had 
usually  been  applied,  but  in  a  mechanistic  way,  with  the  allocation 
being  based  on  isolated  tasks. 

WHO  IS  THE  USER? 

The  cost  of  adapting  users  to  the  system  through  training  is  usually 
far  greater  than  the  cost  of  changing  hardware  and  software  during  the 
early  stages  of  system  development.  MANPRINT  recognizes  this  via 
the  Target  Audience  Description  (TAD).  To  ensure  usability,  it  is  im¬ 
portant  to  understand  and  quantify  those  capabilities  and  characteristics 
of  the  user  that  are  going  to  impact  total  system  performance. 

Knowing  that  the  user  is  a  human  being  is  not  really  sufficient.  The 
characteristics  that  must  be  known  to  guide  successful  system  develop¬ 
ment  include:  aptitude  for  various  tasks,  existing  knowledge,  organiza¬ 
tional  structure,  etc.  Where  real  defense  systems  are  concerned,  it  is 
often  very  detailed  infoitnation  on  the  user’s  capability  and  existing 
knowledge  base  that  will  determine  if  the  task  would  be  better  handled 
by  human  or  machine.  The  characteristics  that  are  normally  cited  in 
illustrations  of  function  allocation  in  human  factors  texts  are  usually  so 
general  that  they  could  not  help  in  a  practical  vyay.  Also,  most  of  the 
examples  of  allocation  have  centered  around  the  pilot's  cockpit  and  air 
traffic  controller’s  workstations.  From  a  MANPRINT  standpoint,  the 
user  variability  to  be  accommodated  in  the  design  of  such  systems  is 
small  compared  with  that  which  may  be  required  for  an  infantry  com¬ 
mand  system  to  be  exported  throughout  the  world.  It  is  interesting  to 
note  that  both  of  the  former  user  groups  are  subject  to  very  stringent 
selection  criteria. 

WHAT  IS  THE  USER'S  JOB? 

One  of  the  principal  lessons  that  has  emerged  from  the  application  of 
MANPRINT  has  been  the  need  to  identify  the  jobs  of  the  users.  This 
must  include  all  the  component  tasks  that  the  users  will  have  to  under¬ 
take,  not  merely  on  the  system  under  development,  but  also  on  other 
systems  that  they  will  be  required  to  operate,  as  well  as  tasks  that 
originate  from  their  day-to-day  military  duties.  In  many  cases,  the  allo¬ 
cation  of  system  tasks  to  human  or  machine  is  governed  by  the  task 
(and  work)  loading  imposed  by  activities  outside  the  immediate  system. 
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Mechanisms  arc  having  to  be  Found  that  can  identify  and  communicate 
these  outside  tasks  to  the  system  developers  in  industry  in  a  meaningful 
way. 

WHAT  IS  THE  CONTRACTOR’S  TASK? 

The  contractor's  task  (Figure  3.1)  consists,  first,  of  analyzing  the 
customer’s  requirement  and  translating  it  into  a  mission  analysis  and  a 
description  of  the  users  that  the  customer  will  have  available.  The  latter 
is  referred  to  as  the  Target  Audience  Description  (or  TAD).  The  contrac¬ 
tor's  task  then  consists  of  generating  options  that  can  match  the  mis¬ 
sion  requirements  and  analyzing  the  tasks  that  those  options  entail.  The 
contractor’s  MANPRINT  task  is  to  dctcmiinc  which  of  the  feasible  so¬ 
lutions  best  matches  the  skills,  abilities,  aptitudes,  knowledge,  etc., 
that  the  target  audience  possesses.  It  is  during  this  matching  that  the 
allocation  process  is  used  to  balance  the  tasks  within  each  option  be¬ 
tween  human  and  machine. 

TIMETABLE  FOR  MANPRINT  (FUNCTION  ALLOCATION) 

When  MANPRINT  was  first  introduced  to  British  Aerospace,  many 
people  expected  to  be  able  to  pick  up  a  MANPRINT  package  and  apply 
it  onec  they  had  designed  their  system.  This  was  the  way  human  aspects 
such  as  training  had  been  handled  in  the  past.  A  major  part  of  imple¬ 
menting  MANPRINT  within  industry  has  been  explaining  to  system 
developers  that  MANPRINT  needs  to  be  applied  throughout  the  whole 
of  the  development  life  eyele.  The  major  input,  however,  should  be  in 
the  early  pha.scs  of  concept,  feasibility,  and  project  definition  (in  UK 
tcnninology).  Changes  to  the  allocation  of  tasks  after  project  definition 
are  usually  llxcs  to  cover  technological  shortcomings. 

COMMERCIAL  CONSTRAINTS 

The  allcKation  of  tasks  and  functions  between  human  and  machine 
does  not  take  place  in  a  vacuum.  The  prcKCSs  of  alIcKation  has  to  rec¬ 
ognize  that  certain  tasks  may  be  allocated  as  a  result  of  constraints  that 
range  from  technology  to  politics. 
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TECHNOLOGICAL  CONSTRAINTS 

Technological  constraints  may  include  the  need  to  incorporate  a  piir- 
ticular  piece  of  equipment  because  the  customer  has  made  considerable 
investments  in  the  item  and  insists  that  it  he  incorporated.  The  technol¬ 
ogy  may  be  requia'd  to  cope  with  a  small  proportion  of  cases,  hut, 
since  it  has  to  he  provided  anyway,  it  may  have  to  cover  all  cases. 

ORGANIZATIONAL  CONSTRAINTS 

There  are  often  considerable  constraints  regarding  which  users  within 
a  cu.stonier’s  organization  have  authority  to  undertake  particular  tasks. 
The  organizational  constraints  within  groups  of  operators  can  have  a 
profound  inllucncc  on  the  allocation  prcxrcss. 

POLITICAL  AND  LEGAL  CONSTRAINTS 

With  changes  in  legislation  and  associated  commercial  responsibility 
and  accountability,  there  arc  now  many  more  tasks  that  it  is  not  possi¬ 
ble  to  allcKatc  to  the  human  component.  The  incrca.scd  knowledge  of 
toxic  suh.stanccs,  sensitivity  to  public  opinion,  and  the  fear  of  litigation 
arc  causing  manufacturers  to  err  very  much  on  the  side  of  caution. 
Many  tasks  that  could  be  done  “better"  by  humans  must  now  be  as¬ 
signed  to  machines. 

COMPATIBILITY  CONSTRAINTS 

Systems  arc  now  so  complex  and  costly  that,  where  possible,  the 
reuse  of  existing  designs  and  the  increased  use  of  off-the-shelf  systems 
arc  the  order  of  the  day.  It  is  unusual  to  start  with  a  blank  piece  of  pa¬ 
per,  and  .so  the  llcxibility  available  in  allocation  of  functions  is  imme¬ 
diately  limited.  In  addition,  the  inllucnccs  of  the  “outside  system"  tasks 
the  user  must  perfonn  will  modify  the  scope  for  allocation  (see  the  sec¬ 
tion  "What  Is  the  User's  Job?"  above). 

RESOURCE  CONSTRAINTS 

The  drivers  for  the  allocation  process  in  many  modern  systems  are 
often  the  skill  levels  of  personnel  available  to  the  customer  and  the 
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training  time  the  customer  can  afford.  Training  is  probably  the  most 
significant  aspect  that  has  been  poorly  represented  in  any  of  the  tradi¬ 
tional  allocation  exercises. 

In  many  of  the  through-life  cost  calculations,  personnel  and  training 
costs  can  be  many  times  the  development  and  procurement  costs.  In 
these  instances,  the  availability  of  previously  trained  personnel  and 
training  courses  are  beginning  to  influence  the  allocation  process  on  the 
prime  equipment  design. 

CONCURRENT  ENGINEERING 

There  is  a  move  within  industry  toward  the  concept  of  concurrent 
engineering.  In  the  past,  great  efforts  have  been  made  to  get  the  re¬ 
quirements  correct  and  adequately  documented  in  such  a  way  that  the 
team  responsible  for  the  next  phase  in  the  system  development  life  cy¬ 
cle  could  work  from  it  alone.  Concurrent  engineering  is  a  recognition 
that,  for  the  complex  systems  that  constitute  modem  defense  equip¬ 
ment,  this  approach  is  no  longer  possible.  The  gestation  period  of  mod¬ 
ern  systems  can  be  up  to  15  years  and,  with  the  likely  technological 
changes,  this  can  cause  a  need  for  modification  and  consequently  reallo¬ 
cation.  It  is  essential  that  each  person  involved  with  the  development  of 
the  system  be  aware  of  the  requirements  and  constraints  that  apply  to 
others. 


ARE  FUNCTIONS  TOO  BIG  TO  ALLOCATE? 

The  traditional  human  factors  texts  often  show  a  large  number  of 
steps  that  need  to  be  followed  to  apply  ergonomics  successfully  to  a 
project.  These  include  the  following  (UK  Ministry  of  Defence,  1989): 

•  system  requirements  analysis  (or  mission  analysis); 

•  functional  analysis; 

•  allocation  of  functions; 

•  task  synthesis; 

•  task  description; 

•  task  analysis; 
etc. 

Jordan  (1963)  attributed  the  failure  to  develop  a  satisfactory  method¬ 
ology  for  allocation  of  functions  to  the  fault  of  comparing  humans  with 
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niacliincs.  In  the  majority  of  eases,  the  two  have  to  work  in  a  coniple- 
nientary  manner  to  achieve  functional  goals  successfully.  In  modem 
defense  systems,  the  majority  of  functions  need  hoih  humans  and  ma¬ 
chines  to  undertake  complementary  tasks. 

During  the  development  of  the  MANPRINT  program  for  British 
Aerospace  Dynamics,  the  .search  has  been  for  a  simple,  practical  frame¬ 
work  that  can  he  used  for  as  many  dilTcrent  projects  as  possible.  It  has 
been  found  that  it  can  be  very  difllcult  to  explain  the  difference  between 
a  funetion  and  a  task  to  engineers  who  have  not  been  brought  up  in  the 
human  laetors  community.  Similarly,  mission  analysis  and  functional 
analysis  hlend  together  to  such  an  extent  that  considerable  time  was 
being  spent  defining  the  boundary  on  a  projeet-hy-project  basis.  Tlic 
solution  that  is  beginning  to  he  adopted  is  to  remove  the  term  fnne- 
tional  and  to  refer  only  to  missions  and  tasks. 

MANPRINT  experience  suggests  that  it  is  nearly  always  tasks  that 
we  all(K'ate  when  trying  to  design  for  the  user.  Throughout  the  remain¬ 
der  of  thi.s  paper,  the  phrase  allocation  of  tasks  is  used  to  signify  allo¬ 
cation  of  1  unction/task  and  function  allocation. 


THE  ALLOCATION  PROCESS 

There  are  severe  problems  in  trying  to  apply  Pitts-type  lists  to  mod¬ 
ern  systems.  This  is  due  largely  to  the  vastly  inereased  capabilities  of 
machines.  When  function  allcKation  came  into  being  as  a  concept  in  the 
early  !95().s,  the  allocation  of  functions  between  human  and  machine 
was  fixed,  barring  major  redesign,  very  early  in  the  design  cycle.  Sys¬ 
tems  were  relatively  simple,  and  the  prcKxss  of  allocation  was  fairly 
obvious.  Many  of  the  early  lists  now  look  like  SOTBOs  (statements  of 
the  blindingly  obvious). 

The  development  of  the  MANPRINT  program  has  revailed  that  a 
different  approach  to  the  allocation  problem  could  he  hencficial.  This 
approach  consists  of  identifying  those  tasks  for  which  a  human  is 
clearly  “host”  or  is  required  for  legal  (or  other)  rea.sons,  and  building  a 
coherent  joh  structure  around  those  tasks.  In  additiiin  to  providing  a 
.sensible  joh  content,  the  dctemiination  of  an  optimal  workload  is 
probably  the  clearest  single  driver  for  this  alUxation  pRKXss. 
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WHY  DOES  THE  TRADITIONAL  APPROACH 
CAUSE  DIFFICULTIES? 

The  traditional  approach  causes  difficulties  simply  because  the  ma¬ 
chine  content  of  the  system  has  changed  so  much  since  1951 .  As  high¬ 
lighted  in  the  previous  section,  humans  and  machines  perform  tasks  in 
a  complementary  manner  to  fulfil  functions  or  sub-mission  goals. 
While  these  higher-level  goals  may  have  an  obvious  structure,  the  indi¬ 
vidual  tasks  that  are  necessary  to  achieve  them  may  not  in  themselves 
have  that  logical  structure  when  taken  in  isolation.  Laughery  and 
Laughery  (1987)  make  the  point  that  “a  function  can  be  viewed  as  a 
logical  unit  of  behavior  of  a  human  or  machine  component  that  is  nec¬ 
essary  to  accomplish  the  mission  of  the  system.”  When  dealing  with 
tasks,  the  logical  units  may  not  be  present.  Allocation  of  these  tasks  to 
cither  human  or  machine  purely  on  the  basis  of  which  can  do  that  task 
best  often  results  in  the  human’s  being  given  those  tasks  that  are  too 
dil'fieuli  or  expensive  to  automate. 

While  machines  can  operate  on  a  task-by-task  basis,  humans  faced 
with  a  random  selection  of  tasks  that  have  little  logical  connection  tend 
not  to  perform  very  well.  The  automation  represented  by  the  allocation 
of  tasks  to  the  machine  can  remove  many  of  the  signposts  from  the 
user's  mental  model  of  the  process.  This,  in  turn,  leads  to  the  user's 
inability  to  provide  the  resource  of  last  resort,  which  is  often  the  reason 
for  humans  to  remain  included  in  the  automated  system. 

WHICH  TASKS  DO  HUMANS  DO  BETTER 
THAN  MACHINES? 

It  could  be  argued  that  most  tasks  that  can  be  clearly  specified  can 
usually  be  done  better  by  machine.  This  is  typified  by  the  fact  that  re¬ 
cently  computers  have  been  beating  chess  grand  masters  on  a  regular 
basis. 

There  are  many  development  engineers  who  believe  in  automating  the 
humans  out  of  the  system,  since  "people  are  a  problem."  Bainbridge 
(1987)  notes  “the  ironies  of  automation.”  The  first  concerns  the  system 
designers'  perception  of  the  human  operator  as  unreliable  and  inefficient 
and  better  replaced  by  automation,  and  the  second  leaves  the  operator  to 
do  the  tasks  the  system  designer  cannot  think  how  to  automate. 
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One  of  the  reasons  often  given  for  including  humans  in  defense  sys¬ 
tems  is  so  that  they  can  make  decisions.  This  usually  means  making 
decisions  with  insufficient  information  since,  if  all  the  information 
were  available,  the  machine  would  probably  reach  a  correct  solution 
more  rapidly.  Hitchings  (1992),  building  on  the  work  of  Klein,  sug¬ 
gests  that,  in  most  time-constrained  strategic  decision  making  tasks, 
“satisficing”  takes  place.  This  process  consists  of  matching  the  current 
problem  with  one  that  has  been  encountered  before  and  activating  solu¬ 
tions  that  appeared  to  be  effective  on  previous  occasions.  The  user 
checks  that  the  responses  are  in  line  with  his  or  her  predictions.  If  the 
responses  are  at  variance  with  expectations,  a  further  matching  takes 
place.  This  approach  to  decision  making  relies  on  the  user’s  having  an 
understanding  of  how  the  system  behaves.  Indiscriminate  automation 
can  mask  this  essential  overview  and  is  one  of  the  prime  reasons  for  the 
current  MANPRINT  approach. 

The  one  area  where  the  human  still  appears  to  be  better  and  quicker 
than  the  machine  is  in  image  processing.  There  are  still  good  reasons 
for  placing  humans  in  such  vulnerable  situations  as  military  aircraft. 
For  example,  human  beings  are  very  good  at  detecting  that  something 
seems  odd.  They  may  not  know  what  is  odd  or  why,  but  the  very  rec¬ 
ognition  of  an  inconsistency  could  be  vital  in  a  hostile  environment. 

BUILDING  JOBS 

It  is  becoming  more  important  that  the  user's  mental  model  of  the 
system  be  established  early  in  the  design  process.  If  the  unique 
strengths  of  the  human  operator  are  to  be  capitalized  upon,  then  the  way 
the  operator  perceives  the  system  must  be  understood.  The  jobs 
(positions,  in  US  parlance)  that  the  operator  must  perform  need  to  be 
designed  to  ensure  that  the  way  the  operator  views  the  system  results  in 
the  performance  of  actions  the  system  designer  would  have  intended. 
There  are  two  points  here:  first,  the  user  may  view  the  system  in  a  dif¬ 
ferent  way  from  the  system  designer;  and,  second,  the  user  is  there  to 
cope  with  situations  the  system  designer  could  not  predict. 

In  many  cases,  it  is  better  to  give  to  humans  tasks  that  would  have 
been  done  better  by  machine,  but  without  which  they  would  not  have  a 
complete  enough  picture  of  the  world  to  perform  those  tasks  that  are 
their  remit.  Without  constant  exposure  to  the  “big  picture,”  it  is  doubt¬ 
ful  if  many  of  the  potential  users  of  modem  defense  systems  will  have 
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sufficient  understanding  of  the  system’s  inner  workings  to  be  able  to 
intervene  successfully  in  case  of  either  an  equipment  malfunction  or 
changes  in  the  environment. 

The  challenge  is  to  discover  how  the  users  visualize  the  system  and 
ensure  that  any  action  they  may  take  is  not  at  variance  with  the  intent 
of  the  system  developers  because  of  their  different  perceptions  of  the 
system.  If  there  is  a  conflict,  it  is  salutary  to  remember  that  the  system 
designer  may  only  live  with  the  system  for  5  to  10  years,  while  the 
user  has  it  for  25! 

WORKLOAD  AS  THE  ALLOCATION  METRIC 

The  foregoing  was  theory.  How  do  we  accomplish  allocation  of  tasks 
in  practice?  First,  we  assign  tasks  according  to  a  set  of  SOTBOs.  That 
is,  we  assign  those  tasks  that  require  the  cube  roots  of  a  five-digit  num¬ 
ber  to  be  calculated  within  10  msecs  to  the  machine,  and  assign  the 
launching  of  nuclear  ballistic  missiles  to  humans. 

Second,  we  assess  what  understanding  the  human  needs  of  the  total 
system  in  order  to  perform  his  or  her  tasks  correctly  and  efficiently. 
From  this,  we  assess  which  other  tasks  the  operator  could  be  involved 
in  that  would  help  to  develop  and  reinforce  an  adequate  mental  model  of 
the  system.  In  other  words,  we  assign  tasks  to  ensure  that  the  action  the 
user  performs  corresponds  sufficiently  with  the  system  developers'  mod¬ 
els  of  the  system  so  that  a  satisfactory  outcome  is  achieved. 

Third,  the  workload  on  the  user  must  be  assessed.  It  is  this  step  that 
should  determine  which  tasks  are  given  to  the  human  component,  and  it 
is  also  this  step  that  should  be  the  arbiter  of  which  tasks  can  or  should 
be  the  subject  of  automatic  reallocation.  (If  ease  of  automation  is  used 
to  determine  allocation  of  tasks,  situations  arise  such  as  that  found  on 
the  civil  airliner  flight  deck.  Automation  of  the  boring  long-haul  por¬ 
tions  of  the  route  are  easiest  and  have  been  incorporated  in  the  majority 
of  modem  aircraft.  However,  this  automation  takes  place  when  the  air 
crew  workload  is  negligible  anyway.  A  change  of  runway  on  the  final 
approach  or  a  change  to  a  holding  pattern  requires  the  pilot  to  become  a 
data-entry  operative  instead  of  looking  out  of  the  windscreen  in  what  is 
clearly  a  confused  situation.) 

As  stated  earlier,  much  of  the  work  on  allocation  has  been  with  very 
constrained  populations  and  working  environments:  fast  jets,  air  traffic 
control,  and  nuclear  power  plants.  In  most  cases,  the  target  audience  is 
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highly  screened  and  uniform.  The  work  patterns  are  constrained  and  of 
fixed  duration.  These  circumstances  are  rare  for  large  numbers  of  mili¬ 
tary  systems  that  have  to  be  developed  under  the  MANPRINT  program. 
The  variability  within  most  user  groups  eould  cause  optimal  allocation 
to  change  from  one  end  to  the  other.  It  ean  often  be  necessary  to  design 
systems  that  will  be  issued  to  groups  ranging  from  Armed  Forces 
Qualification  Test  categories  Cat  I  to  Cal  IV. 

In  addition,  when  dealing  with  systems  where  lime  on  duty  can 
greatly  exceed  that  seen  in  cockpits,  the  change  in  user  performance 
with  fatigue  will  also  change  the  optimal  allocation  for  the  beginning 
and  end  of  a  watch  period. 

The  MANPRINT  activities  that  have  been  undertaken  indicate  that  it 
is  this  optimizing  of  the  workload  that  should  be  the  driver  to  the  allo¬ 
cation  of  function  within  any  system.  What  are  required  are  simple 
workload  prediction  tools  that  ean  be  used  early  and  quickly.  Many  of 
the  tools  that  do  exist  have  been  designed  for  very  demanding  situations 
such  as  the  cockpit  of  a  modern  fast  jet.  The  precision  being  sought  for 
these  tools  is  neither  necessary  nor  appropriate  for  the  majority  of  allo¬ 
cation  activities  because  of  the  variability  that  is  to  be  expected  in  the 
performance  of  the  user  populations. 

ADAPTIVE  AND  DYNAMIC  ALLOCATION 

Both  dynamic  and  adaptive  allocation  systems  have  been  proposed  to 
avoid  the  problem  of  the  system  designers’  having  to  make  the  deci¬ 
sions  on  allocation  between  human  and  machine.  Rouse  (1981)  consid¬ 
ered  some  of  the  interesting  aspects  of  dynamic  allocation  of  tasks,  par¬ 
ticularly  the  aspect  of  who  is  in  control.  Does  the  human  delegate 
procedural  aspects  of  the  job  to  the  machine,  or  docs  the  machine  moni¬ 
tor  the  human’s  activities  and  assume  control  of  those  facets  that  arc  not 
being  attended  to  adequately? 

The  dynamic  allocation  technique  currently  used  most  commonly 
within  defense  industries  is  that  of  providing  default  settings.  Where 
tasks  can  be  performed  either  by  human  or  machine,  the  human  opcratoi 
is  given  the  opportunity  to  override  the  default  condition  if  the  operator 
feels  she  or  he  has  access  to  better  information  than  the  machine.  While 
this  is  not  a  very  adventurous  approach,  it  is  pragmatic  and,  most  im¬ 
portantly,  it  docs  meet  with  the  approval  of  the  users. 
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Dynamic  allocation  will  carry  with  it  a  number  of  quality  and  safety 
problems.  In  particular,  there  is  likely  to  be  considerable  discussion 
with  the  Ordnance  Board  on  how  to  validate  the  safety  of  any  system 
that  changes  its  mode  of  control.  Audits  both  for  quality  and  for  Failure 
Mode  Effects  &  Criticality  Analysis  (FMECA)  will  need  very  careful 
consideration  and,  again,  validation.  Even  then,  meeting  the  standards 
required  by  the  Ordnance  Board  may  be  very  difficult. 

THE  WAY  FORWARD 

Developing  the  British  Aerospace  MANPRINT  program  has  revealed 
that  the  two  crucial  formal  activities  are  the  preparation  of  the  Manufac¬ 
turer's  MANPRINT  Management  Plan  (M^P)  and  the  creation  (and 
maintenance)  of  the  Concerns  Register.  The  former  ensures  that  thought 
has  been  given  to  both  the  management  and  technical  aspects  of  design¬ 
ing  for  the  user.  The  second  provides  a  formal  record  of  the  problems 
encountered,  solution  paths,  and  final  decisions  regarding  the  way  the 
problem  should  be  overcome.  The  Concerns  Register  has  proved  in¬ 
valuable  on  a  number  of  projects,  since  it  contains  information  on  the 
underlying  assumptions  that  have  been  made  when  selecting  a  particular 
approach.  Many  of  the  MANPRINT  concerns  in  modem  defense  sys¬ 
tems  are  related  to  the  allocation  of  tasks  between  human  and  machine. 
For  this  reason,  a  short-term  aim  has  been  to  modify  the  Concerns  Reg¬ 
ister  to  ensure  that  it  can  capture  the  factors  and  the  thinking  that  goes 
into  allocating  tasks  to  either  human  or  machine.  It  is  also  important 
that  the  record  of  allocation  be  linked  to  the  best  possible  description  of 
the  users  in  question. 

A  long-term  aim  is  to  produce  a  task  database  that  carries  information 
on  learning  difficulty,  retention  times,  etc.,  with  links  to  specific  user 
populations.  The  relative  susceptibility  of  the  tasks  to  fatigue  effects 
and  the  human  resources  needed  are  also  being  included  in  the  database. 
Figure  3.2  shows  where  the  task  database  fits  into  the  current  develop¬ 
ment  of  a  MANPRINT  manpower,  personnel,  and  training  trade-off 
tool.  This  project  is  the  subject  of  a  research  study  within  British  Aero¬ 
space's  Dynamics  Division. 

Based  on  tasks  analyses  of  some  of  the  company's  systems,  a  number 
of  common  tasks  have  been  identified.  For  each  of  these  tasks,  efforts 
are  being  made  to  establish  how  performance  on  these  tasks  will  vary 
with  different  user  populations.  Because  of  the  potential  enormity  of 
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this  undertaking,  we  are  confining  our  task  base  to  those  few  tasks  that 
are  common  to  a  number  of  our  systems.  By  constraining  the  scope  of 
the  database,  it  is  hoped  that  it  will  be  possible  to  build  directly  from 
project  work  and  that  an  assessment  of  the  approach  can  be  carried  out 
without  committing  large  amounts  of  funds. 

CONCLUSIONS 

Allocation  of  functions  (tasks)  in  complex  weapon  systems  tradition¬ 
ally  is  done  poorly  and  is  often  done  for  the  wrong  reasons.  It  is  impor¬ 
tant  to  recognize  the  users'  characteristics  and  capabilities  in  the  alloca¬ 
tion  process. 

It  is  not  sufficient  merely  to  assess  suitability  of  tasks  for  operator  or 
machine  implementation.  The  op)erator  needs  to  retain  sufficient  under¬ 
standing  of  the  system  to  perform  satisfactorily  and  predictably,  while 
not  being  loaded  beyond  his  or  her  capabilities.  The  British  Aerospace 
MANPRINT  developments  indicate  some  of  the  practical  solutions  to 
task  allocation  and  some  pointers  for  future  attention. 
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HUMAN  FUNCTIONS  AND 
SYSTEM  FUNCTIONS' 

D.  Bcevis 


I'ypicallw  function  andlyscs  concentrate  on  the  functions 
necessary  to  meet  systefu  reifuirenients:  they  seldom  address 
all  the  functions  performed  hy  humans.  Crew  functions  sut  h 
as  supervision,  ntonitorin^,  direction,  consultatioti,  and 
training  are  not  included  in  function  analyses  or  itt  the  alio- 
('(ition  of  functions.  The  reason  is  that  such  human  functions 
are  assumed  or  are  identified  only  onee  function  allocation 
decisions  have  been  made.  Yet  the  performanee  of  these  hu¬ 
man  functions  can  have  a  major  influence  on  the  desiiin  and 
performance  of  tnanned  systettis.  As  one  e.xatnple,  a  major 
hitman  factors  eni^ineerini^  contribution  to  the  CP-NO  tnari- 
time  patrol  aircraft  was  the  crew  compartment  layout.  The 
layout  was  predicated  on  the  need  to  produce  an  effective 
crew  compartment  that  faeilitaied  crew  activities  sue  h  as  su- 
pervision,  task  off-loading*,  assistance,  and  trainin}*.  Yet  none 
of  the  Junction  analyses  prodtu  ed  for  the  CP- 140  systems  in¬ 
cluded  those  human  functions.  I'he  crew  compartment  layout 
was  est(d)lished  in  parallel  with  the  systems  en\^ineerin^  ef¬ 
forts  that  established  the  functional  analyses.  I'he  approach 
to  analyzing  the  compartment  reipiirements  and  the  human 
and  sYstem  functions  is  deserihed.  It  is  concluded  that  ana¬ 
lysts  must  consider  human  Junctions  as  part  of  their  Junction 
allocation  decisions. 


'('opyrighl  Her  Mujcsly  'I'he  yuccn.  in  Righl  of  C’niuida.  ;is  icprcscnlcd  by 
Ihc  Minislcr  ol  Nulioiud  Dclcncc.  Rcprinlcd  wilh  pcrniission. 
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INTRODUCTION 

Despite  the  human  focus  of  ergonomics  and  human  factors,  most 
approaches  to  function  allocation  treat  the  human  as  a  mechanism,  the 
abilities  of  which  are  comparable  to  those  of  a  machine.  A  few  ap¬ 
proaches  have  tried  to  widen  the  scope  of  the  function  allocation  analy¬ 
sis  to  include  specific  human  needs.  Fitts  (1962)  raised  the  question  of 
job  satisfaction.  Clegg,  Ravden,  Corbett,  and  Johnson  (1989)  argued 
that  function  allocation  should  include  human  health  and  safety  consid¬ 
erations  in  the  decision.  Drury  (1994)  expanded  on  this  approach  to 
include  the  following  factors  in  the  function  allocation  decision: 

•  System  effectiveness 
errors/reliability 
speed 

maintainability 
weight/size  where  limiting 

•  System  efficiency 
initial  cost 
running  cost 
disposal  cost 

•  Human  well-being 
safety 

health 

satisfaction 

None  of  these  approaches,  however,  takes  into  account  the  require¬ 
ments  of  the  human  resources  in  a  system  for  interaction,  collaboration, 
monitoring,  supervision,  training,  etc.  Function  analyses  concentrate 
on  the  functions  necessjtry  to  meet  system  requirements  independently 
of  the  means  of  implementation  (Beevis,  1992).  Human  resource  func¬ 
tions  are  not  included  in  the  function  analyses  of  a  system;  they  are 
assumed  or  are  identified  once  function  allocation  decisions  have  been 
made.  Reviews  of  the  function  analyses  of  five  major  military  systems 
(aircraft,  ship  systems,  communication  system)  selected  at  random  did 
not  identify  any  human  resource  functions  such  as  interaction,  collabo¬ 
ration,  monitoring,  or  supervision  (Beevis,  1987). 

This  neglect  of  human  resource  functions  is  part  of  a  general  pattern. 
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As  Edwards  (1993)  noted,  ’’the  balance  of  ergonomics  activities  does  far 
less  than  justice  to  the  issues  of  inter-personal  relationships  in  the  de¬ 
sign  and  management  of  systems,"  Yet  the  performance  of  the  human 
resource  functions  can  have  a  major  influence  on  the  design  and  effec¬ 
tiveness  of  manned  systems.  This  is  reflected  in  the  increasing  empha¬ 
sis  placed  on  crew  performance  by  developments  such  as  the  adoption  of 
crew  resources  management  in  aircraft  operations  (Alkov,  1994;  Wie¬ 
ner,  Kanki,  &  Helmreich,  1993).  The  following  case  study  is  offered  to 
show  that  human  resource  functions  are  important  determinants  of  sys¬ 
tem  design,  and  that  the  imjx)rtance  of  function  allocation  lies  in  its 
contribution  to  a  larger  cycle  of  iterative  analyses. 


SYSTEMS  ANALYSIS  FOR 
THE  CP-140  AURORA  AIRCRAFT 

THE  CP- 140  AURORA  PROJECT 

The  Canadian  Forces  (CF)  CP- 140  Aurora  Maritime  Patrol  Aircraft 
(MPA)  was  developed  in  the  early  1970s  to  replace  the  CP-121  Argus, 
dating  from  the  late  1950s.  The  Argus  used  a  tactical  crew  of  nine  or¬ 
ganized  on  the  traditional  basis  of  assigning  an  operator  to  each  major 
item  of  equipment  (radar,  passive  sonar,  active  sonar,  navigation,  etc.). 
The  functional  requirement  for  the  CP- 140  required  "a  tactical  crew  area 
aft  of  the  flight  station  which  shall  include  accommodations  with  nec¬ 
essary  equipment  for  sensor  station  operators,  tactical  navigator,  and 
combined  routine  navigator  and  communications  operator,  as  directed  by 
the  Department"  (Canadian  Armed  Forces,  1973).  Thus,  the  functional 
specification  for  the  aircraft  implied  a  reduced  crew  complement  and 
defined  some  operator  roles. 

Proposals  received  from  industry,  however,  included  four  different 
crew  concepts,  identified  as  numbers  1  through  4  in  Table  4. 1 .  The 
overall  level  of  mechanization  was  similar  for  all  four  proposals.  Thus, 
the  allocation  of  functions  between  human  and  machine  did  not  account 
for  much  variance  in  the  proposals.  It  was  the  allocation  of  functions  to 
individual  crew  members  that  accounted  for  most  of  the  differences.  The 
bidders  had  established  their  proposed  crew  complements  by  assigning 
system  functions  to  the  individual  crew  members  based  on  considera¬ 
tions  such  as  the  operator's  workload  and  need  for  information.  The 


Table  4,1,  Assignment  of  functions  to  operators  in  four  different  proposals  for  a  maritime  patrol  aircraft 
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human  factors  analysts  had  completed  the  iterative  cycle  shown  in  Fig¬ 
ure  4.1  from  performance  prediction  (stage  5)  back  to  function  alloca¬ 
tion  (stage  3)  to  review  the  implications  of  function  allocations  for 
operator  tasks  and  operator  workload. 

The  analyses  had  been  conducted  at  a  fairly  gross  level.  The  bidders' 
analysis  appeared  to  have  been  made  on  the  basis  of  “second-level”  func¬ 
tion  analyses  of  the  form  “conduct  radar  search,”  or  “operate  passive 
acoustic  sensors.”  This  was  a  deviation  from  the  recommendation  that 
function  allocation  be  based  on  system  functions  analyzed  to  the  third 
or  fourth  level  (Bee vis,  1992),  In  using  higher-level  analyses,  two  of 
the  bidders  had  the  benefit  of  information  from  existing  maritime  patrol 
aircraft,  so  they  were  able  to  base  their  designs  on  existing  systems,  a 
practice  noted  by  Rouse  and  Cody  (1986). 

Two  bidders  did  not  have  such  ad  hoc  information  available  from  ex¬ 
isting  products  but  were  believed  to  have  expertise  in  MPA  design 
available  to  them  from  subcontractors. 

As  can  be  seen  from  Table  4.1,  there  was  general  agreement  in  the 
proposals  about  the  allocation  of  functions  for  tactical  navigation 
(TACNAV)  and  the  operation  of  the  acoustics  subsystems  (ASOs  1  and 
2).  The  major  differences  in  allocation  of  functions  arose  in  the  opera¬ 
tion  of  the  radar  and  navigation  systems  and  the  employmeni  of  other 
nonacoustic  sensors.  These  differences  resulted  in  proposals  for  tactical 
crew  complements  of  six  or  seven  operators,  depending  on  equipment 
fit.  As  might  be  expected,  the  differences  in  function  allocation  and 
crew  composition  resulted  in  quite  different  tactical  crew  compartment 
layouts.  Detailed  reviews  of  the  proposed  crew  compartments  by  human 
factors  specialists  at  the  Defence  and  Civil  Institute  of  Environmental 
Medicine  (DCIEM)  identified  several  areas  in  which  the  proposed  func¬ 
tions  and  crew  complements  would  not  meet  CF  operational  require¬ 
ments  in  the  most  effective  manner  (Patterson  &  Beevis,  1973).  As  a 
result,  DCIEM  was  tasked  by  the  project  management  office  to  develop 
a  CF-preferred  tactical  crew  compartment  concept. 

DEVELOPMENT  OF  THE  CREW  AND 
CREW  COMPARTMENT  CONCEPTS 

To  develop  the  crew  compartment  concept,  the  human  factors  special¬ 
ists  at  DCIEM  reviewed  the  information  that  was  required  for  workplace 


Figure  4.L  Feedback  in  the  human  factors  engineering  analysis  process. 
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layout  (Morgan,  Cook,  Chapanis,  &  Lund,  1963),  including: 

•  the  system  mission  profiles; 

•  spceiHe  tasks  the  operators  would  pcrlorm; 

•  relative  importance,  duration,  and  Frequency  oF  the  tasks; 

•  information  inputs  to  the  operators; 

•  outputs  From  the  operators; 

•  equipment  eommitted  to  the  design; 

•  antieipated  environmental  conditions  (aircraft  movement  etc.). 

Thus,  DCIEM  involvement  in  the  analysis  of  interface  and  workspace 
design  issues  (stage  6  in  Figure  4.1)  resulted  in  reexamination  of  Func¬ 
tion  allocation  decisions  and  operator  task  analysis  (stages  3  and  4  in 
Figure  4.1).  A  variety  of  crew  complements  and  operator  roles  was 
studied,  including: 

•  dedicated  radar  operator; 

•  dedicated  routine  navigator; 

•  dedicated  communications  operator; 

•  combination  oF  routine  navigator  and  communications  operator 
(NAVCOM); 

•  combination  of  navigator  and  radar  operator  (RADNAV). 

Sources  of  information  used  For  this  work  were  observations  of  the 
operations  in  the  (then)  current  CP- 107  Argus  and  observations  of  the 
Royal  Air  Force  (RAF)  Nimrexi  and  US  Navy  (USN)  P-3C  Orion 
MPA.  System  mission,  function  and  task  analyses,  and  time  lines 
(Beevis,  1992)  for  the  proposed  CP- 140  aircraft  were  also  developed  iuxi 
analyzed.  This  information  was  used  to  identify  constraints  on  the  allo¬ 
cation  of  operator  roles  and  functions  and  to  review  possible  function 
allocations. 

Based  on  experience  with  the  CP- 107  Argus,  it  was  concluded  that  a 
taetical  navigator  (TACNAV)  similar  to  the  Argus  tactical  coordinator 
(TACCO)  would  be  able  to  handle  all  crew  coordination  duties,  particu¬ 
larly  given  the  integration  of  .sensor  and  display  systems  available  in 
the  (then)  new  generation  of  antisubmarine  warfare  equipment.  The 
RAF  concept  of  a  walking  tactical  crew  ccx)rdinator  was  Judged  to  be  a 
function  of  the  Nimrcxl  crew  compartment  layout  and  not  requiral  for 
the  CP- 140.  A  review  of  USN  experience  with  the  combined  naviga¬ 
tor/communicator  (NAVCOM)  position  in  the  P-3C  aircraft  suggested 
that  such  a  role  or  position  was  feasible  for  the  CP- 140.  Although  the 
RADNAV  role  was  Justified  by  one  bidder  as  involving  minimum 
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change  to  existing  CF  specialties  and  training,  the  question  of  retrain¬ 
ing  for  the  proposed  roles  was  not  considered  in  detail  by  DCIEM, 

The  question  of  crew  structure  had  to  be  resolved  early  enough  to 
permit  the  development  of  the  necessary  training  program,  however. 
Therefore,  operational  units  prxxluccd  position  papers  on  training,  enew 
complement,  and  the  two  most  contentious  function  allocations: 
NAVCOM  and  RADNAV.  Two  position  papers  paxluced  conllicting 
conclusions. 

One  argued  for  the  RADNAV  role,  on  the  basis  of  the  following: 

•  training  requirements; 

•  ’'remoteness”  of  the  communieator  from  taetieal  operations; 

•  the  obvious  relationship  of  radar  to  the  navigation  function; 

•  emergency  situations  that  demanded  immediate  response  by  the 
navigator  for  position  information  and  by  the  communieator  for 
distress  calls; 

•  ability  of  a  RADNAV  to  assi.st  the  TACNAV  in  high  workload 
situations; 

•  the  workload  imposed  on  the  communicator  in  the  event  of  taetieal 
computer  failure. 

The  other  position  paper  noted  that  the  P-3C  NAVCOM  position  was 
"not  without  its  problems"  hut  argued  that  the  di. sad  vantages  of  the 
RADNAV  role  outweighed  those  of  the  NAVCOM.  The  principal  dis¬ 
advantages  were  thought  to  be: 

•  the  high  workload  ass(x:iated  with  the  use  of  radar  and  electronic 
support  measures  (FSM)  systems  in  tactical  situations; 

•  the  need  to  avoid  distractions  to  this  work,  such  as  might  be  caused 
hy  navigation  system  updates; 

•  the  need  to  rotate  different  operators  through  the  function  in  a  tacti¬ 
cal  situation  to  av(hd  vigilance  decrements. 

Overall,  the  major  source  of  disagreement  between  the  two  position 
papers  eoneerned  the  estimate  ol  operator  workload  at  different  times  in 
the  aircraft  mission. 

The  position  papers  that  addressed  the  question  of  crew  development 
and  training  suggested  that  either  of  the  crew  concepts  could  he  trained. 
The  more  difficult  issue  was  the  question  of  taetieal  crew  makeup,  in 
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terms  of  oUlccrs  and  noncommissioned  olTiecrs  (NCOs).  It  was  this 
latter  consideration  that  decided  the  argument  in  favor  of  a  NAVCOM 
role  rather  than  RADNAV.  Because  encrypted  communications  must  be 
authorized  hy  an  officer,  the  communications  function  had  to  be  per- 
fomicd  hy  an  ofllecr.  Both  tactical  navigation  and  routine  navigation 
had  to  he  performed  hy  ofllcer  classifications  as  well,  whereas  radar  op¬ 
eration  in  the  Argus  was  performed  hy  NCOs  who  were  rotated  through 
the  position  during  a  mission.  A  crew  that  included  a  RADNAV  posi¬ 
tion  would  have  required  one  ofllcer  for  that  position  as  well  as  one 
each  for  the  TACNAV  and  communicator  positions.  In  contrast,  a  crew 
with  a  TACNAV  and  NAVCOM  would  require  only  two  ofUccrs.  Thus, 
the  allocation  of  functions  to  different  memhers  of  the  crew  was  dccidal 
on  the  basis  of  rank  and  trade  specialty  considerations. 

INFLUENCE  OF  WORKPLACE  DESIGN 
ON  FUNCTION  ALLOCATION 


In  parallel  with  the  review  of  crew  functions,  the  requirements  for  a 
tactical  crew  compartment  "arranged  to  confomi  to  the  hest  human  en¬ 
gineering  practices"  (Canadian  Armed  Forces,  1973)  were  analyzed.  Ob¬ 
servations  of  RAF  Nimrod  operations  highlighted  the  importance  of 
crew  coordination.  The  RAF  used  an  airborne  equipment  operator 
(AEO)  as  a  walking  tactical  ccwrdinator  who  moved  from  crew  station 
to  crew  station  coordinating  crew  operations,  instructing,  and  resolving 
conflicts  and  ambiguities.  Observations  made  aboard  a  USN  P-3C  air¬ 
craft  when  an  unforeseen  event  (x:currcd  during  the  mission  con  tinned 
the  importance  of  crew  coordination,  particularly  for  consultation  imd 
problem  solving.  It  was  noted  that  the  compartment  of  the  P3-C  had 
been  arranged  to  minimize  unncce.ssary  crew  interaction  and  to  require 
such  interaction  through  cither  the  mission  computer  or  the  intercom. 

Analytically,  the  issue  became  one  of  identifying  the  advantages  of 
and  requirements  for  an  integrated  tactical  crew  compartment.  It  was 
argued  that,  in  a  well-planned  compartment,  emphasis  is  placed  on  close 
physical  proximity  and  face-to-face  communications.  In  this  context,  it 
was  noted  that  the  claim  by  one  bidder  that  two  crew  members  would  be 
able  to  load-share  was  not  supported  by  the  design  of  the  compartment, 
which  separated  them  physically. 
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The  Following  were  seen  to  be  the  potential  advantages  oF  an  inte¬ 
grated  layout  (Patterson  &  Beevis,  1973): 

i)  It  encourages  a  coordinated  team  elTort: 

•  should  one  operator  be  overloaded,  another  crew  member  can 
assist,  provided  tbeir  stations  are  adjacent; 

•  other  crew  members  can  be  consulted  in  cases  ol  ambiguity  or 
con llic ting  information. 

ii)  Senior  crew  members  ean  more  easily  monitor  the  performance  of 
junior  crew  members. 

iii)  Crew  rotation  is  facilitated: 

•  crew  members  can  maintain  an  overview  of  the  tasks  at  adja¬ 
cent  consoles,  to  which  they  may  rotate; 

•  in-lligbt  training  is  facilitated,  since  face-to-face  communica¬ 
tion  is  possible,  leaving  the  intercom  free  for  operational  in¬ 
formation; 

•  reversionary  modes  of  operation  are  possible,  in  the  event  of 
equipment  failure; 

•  crew  interaction  maintains  attention  during  long  periods  of 
monitoring. 

These  advantages  imj)lied  the  following  human-subsystem  functions: 

•  coordination; 

•  consultation; 

•  resolution  of  ambiguity; 

•  crew  performance  monitoring; 

•  maintenance  of  awarene.ss  of  .system  state; 

•  training; 

•  reversionary  mexie  operation,  and; 

•  maintenance  of  alertness. 

None  of  the  function  analyses  provided  by  the  bidders  or  prepared  by 
the  Canadian  Department  of  Defence  (DND)  included  these  functions. 
Task  analyses  prcxiucal  by  contraetors  and  the  DND  following  the  re¬ 
view  of  the  propo.sals  provided  more  detail  related  to  the  operation  of 
the  aircraft  equipment  but  did  not  include  tasks  rellecting  human  .sub¬ 
system  functions.  “Function  allocation’’  itself  was  not  a  work  item  in 
the  human  factors  engineering  project  plan  provided  by  the  two  contrac¬ 
tors  selected  for  the  subsequent  project  dellnition  studies.  Presumably, 
they  considered  the  function  allocation  analysis  to  be  complete.  Yet  the 


Human  Functions  and  System  Functions 


73 


human  subsystem  functions  listed  above  had  a  major  inllucncc  on  the 
development  of  the  concept  of  the  erew  compart meni,  as  well  as  impli¬ 
cations  for  operator  workload  and  equipment  design.  The  features  of  iin 
integrated  crew  compartment  were  incorporated  in  a  set  of  design  rc- 
quirements  (Patterson  &  Beevis,  1973): 

•  the  tactical  navigation  station  should  be  adjacent  to  the  routine 
navigation  station; 

•  the  acoustic  sensor  stations  should  be  adjacent; 

•  the  nonacoustic  sensor  stations  should  be  adjacent; 

•  the  acoustic  sensor  stations  and  the  nonacoustic  sensor  stations 
need  not  be  adjacent; 

•  both  the  acoustic  sensor  stations  and  the  nonacoustic  sensor  sta¬ 
tions  should  be  as  close  as  possible  to  the  tactical-navigation 
and  routine  navigation  stations. 

These  requirements  were  embodied  in  two  crew  compartment  designs 
lor  the  CP- 140  that  were  produced  as  simple  mock-ups.  The  concept 
was  developed  further  through  extensive  analysis  and  mock-up  trials  by 
DCIEM  using  operators  with  experience  in  a  variety  of  MPA.  The  re¬ 
sults  of  those  analyses  were  then  passed  to  the  two  contractors  selected 
and  funded  for  project  dcllnition. 

Late  in  the  project,  the  value  of  the  integrated  crew  compartment  was 
questioned,  compared  to  the  lesser  cost  of  adopting  the  design  of  an 
existing  aircraft.  The  question  was  interpreted  in  terms  of  the  contribu¬ 
tion  to  system  effectiveness  of  the  integrated  compartment  design.  As 
noted  above,  the  function,  task,  and  workload  analyses  conducted  by  the 
contractors  performing  system  dcllnition  studies  had  not  iiddrcsscd  the 
functions  that  were  facilitated  by  the  crew  compartment  layout.  Fortu¬ 
nately,  questionnaire  surveys  to  identify  actual  operator  roles,  duties, 
functions,  and  tasks  in  USN  P-3C  and  S-3A  aircraft  did  identify  tasks 
related  to  coordination  and  supervision  (Helm,  1972,  1975). 

To  address  the  contribution  of  the  integrated  crew  compartment  con¬ 
cept,  the  P-3C  function  and  task  descriptions  were  compared  with  the 
equipment  fit  and  tasks  anticipated  for  the  CP- 140.  Sufllcient  common¬ 
ality  was  found  at  the  system  level  to  justify  applying  the  task  descrip¬ 
tions  for  the  P-3C  to  the  proposed  CP- 140.  (^f  418  tasks  for  the 
TACCO  identilled  in  the  USN  P-3C  survey  (Helm,  1972),  106  were 
judged  to  be  facilitated  by  the  adoption  of  the  integrated  compaiiment 
design  (Beevis,  1975).  Examples  of  those  tasks  are  shown  in  Table  4.2. 


Table  4.2.  Examples  of  tasks  performed  by  P-3C  tactical  coordinator  (TACCO)  that  involved  coordination, 
supervision,  and  crew  monitoring 


Source:  From  Helm  (1972). 
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On  the  basis  of  that  analysis,  which  related  operator  functions  and  tasks 
to  the  design  of  the  workspace,  the  CF  proceeded  with  the  development 
of  the  integrated  crew  compartment  for  the  CP- 140. 

DISCUSSION 

One  obvious  question  is  whether  the  effort  devoted  to  the  human  re¬ 
source  functions  in  the  CP-140  was  justified.  Crew  functions  and  the 
crew  compartment  design  were  not  tested  in  the  operational  evaluation 
prior  to  phasing  the  aircraft  into  service  (Maritime  Air  Group,  1980). 
Once  the  aircraft  was  in  service,  however,  unpublished  surveys  of  air¬ 
crew  identified  few  major  problems.  In  general,  reports  about  the  crew 
functions  and  workload  have  confirmed  predictions  made  during  the  con¬ 
cept  development.  In  certain  missions,  workload  at  the  NAVCOM  sta¬ 
tion  is  reported  to  be  very  high  for  long  periods.  It  should  be  noted  that 
those  missions  were  not  included  in  the  original  requirements  for  the 
Aurora  and  were  not  included  in  the  mission,  function,  task,  or  work¬ 
load  analyses.  As  for  the  resulting  crew  compartment  design,  there  have 
been  many  favorable  comments  from  aircrew.  A  third-party  review  of 
the  tactical  crew  compartments  of  current  NATO  MPA  judged  the 
Aurora  as  "perhaps  the  best  integrated  multi-crew/avionics  system  [in 
an  MPA]  flying  anywhere  in  the  world"  (Lovesey,  1988.) 

Another  question  is  whether  the  issues  arising  during  the  Aurora  proj¬ 
ect  were  typical.  The  CP- 140  was  not  the  only  DCIEM  project  in 
which  human  subsystem  functions  became  important  determinants  of 
function  allocation  and  crew  station  layout.  Questions  of  collaboration, 
supervision,  and  monitoring  have  arisen  in  several  projects,  including 
the  design  of  ship's  bridges  (Beevis,  1978)  and  the  development  of 
ship's  machinery  control  consoles  (Gorrell  &  Beevis,  1985).  More  re¬ 
cently,  in  the  CF  Light  Helicopter  project,  one  issue  was  that  the 
equipment  fit  might  require  a  change  in  the  crew  concept  from  that  of 
the  existing  CH-136  Kiowa,  in  which  the  pilot  is  the  crew  commander 
and  is  assisted  by  an  NCO.  An  investigation  using  knowledge  elicita¬ 
tion  techniques  among  CH-136  aircrew  identified  four  constructs  that 
distinguished  different  crew  concepts:  structure  and  composition, 
knowledge,  workload,  and  effectiveness  (Poisson,  1989).  Measures  of 
effectiveness  used  in  a  subsequent  computer  simulation  of  the  two  most 
promising  crew  configurations  (pilot/commander  plus  observer,  and 
pilot  plus  mission  commander)  showed  differences  between  the  two 
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configurations.  Those  differences  were  due  to  extensive  differences  in 
communication  between  the  crew  configurations  that  affected  operator 
workload  (Hendy,  Kobierski,  &  Youngson,  1992).  Thus,  the  allocation 
to  different  crew  memb)ers  of  functions  involving  supervision,  coordina¬ 
tion,  consultation,  etc.,  was  again  shown  to  affect  workload,  system 
design,  and  system  effectiveness. 

On  the  more  general  issue  of  function  allocation,  the  CP- 140  case 
study  shows  clearly  that  the  process  of  function  allocation  does  not 
stand  on  its  own,  but  that  it  is  one  of  an  interrelated  series  of  analyses 
that  must  be  reiterated.  Initial  solutions  may  be  obtained  on  the  basis  of 
function  decompositions  to  the  second  level  only.  The  solutions  derived 
from  those  initial  analyses  did  not  converge  to  one  concept,  however, 
but  differed  quite  widely  in  allocation  of  functions  to  different  crew 
members,  in  estimates  of  workload,  and  in  crew  complement.  Further 
iterations  were  necessary  to  converge  to  one  preferred  crew  concept. 
Various  human  factors  engineering  issues  were  addressed  not  in  the 
structured,  sequential  way  described  in  human  factors  texts,  but  in  a 
very  fluid  manner.  This  accords  with  more  recent  observations  that  the 
application  of  human  factors  in  design  involves  a  continually  changing 
problem  environment  (Bums  &  Vincente,  1994).  Rather  than  being 
treated  as  sequential  steps,  the  stages  of  human  factors  engineering 
analysis  shown  in  the  figure  in  the  Executive  Summary  can  be  treated 
as  work  items  that  must  be  completed  (Burns  &  Vincente,  1994). 

In  this  context,  it  is  hard  to  agree  with  criticisms  that  allocation  of 
function  generates  few  particular  results  (Fuld,  1993).  It  may  be  that 
large  tabular  comparisons  of  human  and  machine  capabilities  on  a  third- 
level,  function-by-function  basis  do  not  add  value  to  systems  analysis 
efforts,  but  that  is  not  the  issue  addressed  here.  The  purpose  of  this  pa- 
F>er  is  to  argue  that  function  allocation  goes  well  beyond  the  simple 
concept  of  deciding  whether  a  function  should  be  performed  by  a  ma¬ 
chine  or  a  human. 

Some  may  consider  that  the  issues  raised  are  not  part  of  function  allo¬ 
cation  as  normally  practiced.  Those  issues  were  raised,  however,  to  il¬ 
lustrate  that  the  allocation  of  functions  among  members  of  a  crew  is 
important  and  involves  functions  that  are  uniquely  human.  While  the 
allocation  of  functions  between  humans  and  machines  may  not  be  con¬ 
tentious,  the  allocation  of  functions  among  different  members  of  a  crew 
may  be.  That  some  functions  in  CP- 140  were  allocated  on  the  basis  of 
rank  and  specialty  demonstrates  a  potential  link  between  human  factors 
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engineering  and  manning,  personnel,  and  training  issues  that  is  impor¬ 
tant  for  liveware  (or  human  systems)  integration  (NATO  Defence  Re¬ 
search  Group,  1993). 


CONCLUSIONS 

On  the  basis  of  the  foregoing  case  study,  we  can  draw  several  conclu¬ 
sions. 

First,  although  the  actual  design  process  is  unstructured  rather  than 
sequential,  human  factors  engineering  analysis  stages  such  as  those 
identified  in  the  NATO  review  of  human  engineering  analysis  tech¬ 
niques  (Beevis,  1992)  or  US  MIL-H-46855B  (US  Dept,  ol'  Defense, 
1979)  can  be  used  as  milestones  in  that  process.  Within  the  human 
factors  engineering  process,  function  allocation  contributes  to  the  over¬ 
all  development  of  a  system  concept  through  its  support  to  an  iterative 
cycle  of  analyses.  The  initial  cycle  of  human  factors  engineering  analy¬ 
ses  can  be  completed  using  second-level  systems  functions  if  informa¬ 
tion  is  available  from  existing  systems,  but  further  iteration  is  probably 
required  to  converge  to  a  solution.  Analysts  must  consider  human  re¬ 
source  functions  such  as  collaboration,  monitoring,  supervision,  and 
training  as  part  of  their  function  allocation  decisions.  Personnel  rank, 
specialty,  and  training  may  be  important  determinants  of  function  allo¬ 
cation  decisions  and  may  provide  a  link  for  integrating  manpower,  per¬ 
sonnel,  training,  and  human  factors  engineering  considerations  in  sys¬ 
tem  development. 
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FUNCTION  ALLOCATION  AND  AUTOMATION 
IMPLEMENTATION  IN  THE  US  AIR  FORCE 

J.  W.  McDaniel 


Advances  in  digital  electronics  ami  software  are  causing  revolu¬ 
tionary  changes  in  the  crew  system.  Offered  an  unprecedented 
amount  of  information,  pilots  have  demamled  more  ''situation 
awareness,"  only  to  complain  of  workload  problems.  Many  be¬ 
lieve  effective  function  allocation  has  the  greatest  potential  for 
.solving  these  types  of  problems.  This  paper  discii.sses  the  issues 
(uid  special  problems  associated  with  function  allocation  wul  its 
importance  to  the  design  of  complex  military  systems.  It  also  re¬ 
views  function  allocation  from  the  perspective  of  different  levels, 
from  top-level  management  in  the  US  Department  of  Defense 
(DoD)  down  to  the  human  factors  engineers  that  support  the  pro¬ 
gram  and  the  laboratory  .scientists  and  engineers  that  develop  new 
design  aids.  Modern  crew  system  design  is  a  complex  issue  that 
should  not  be  addressed  piecemeal  but  requires  an  integrated  proc¬ 
ess  and  design  support  system  to  help  manage  the  process. 


INTRODUCTION 

Alter  aerodyniimic  and  propulsion  technologies  matured  in  the  late 
196()s  and  early  I97()s,  the  burgeoning  technologies  of  digital  electron¬ 
ics  and  software  began  to  dominate  aircraft  design  and  are  causing  revo¬ 
lutionary  changes  in  the  crew  system.  F^lcclronic  technology  can  now 
offer  pilots  an  unprecedented  amount  of  information  and  control  in  the 
cockpit.  Pilots  have  responded  by  expressing  a  need  for  more  “situation 
awareness.”  The  avionics  (aviation  electronics)  engineers  eagerly  ai.shed 
to  meet  this  need  with  a  host  of  new  capabilities  so  vast  that  pilots 
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began  to  complain  of  workload  problems.  At  the  same  time,  the  thor¬ 
oughly  investigated  crashes  of  civil  transports  have  increasingly  pointed 
to  sloppy  implementation  of  automation  as  a  cause.  Sparaco  (1994) 
identified  poor  human  factors  engineering  as  the  cause  of  a  crash  of  an 
A320  commercial  transport  in  1992,  saying,  "Complex  human  factor 
issues  that  contributed  to  the  accident  underscore  the  need  to  more  fully 
understand  the  implications  of  man/machinc  interface  as  increasingly 
advaneed  technologies  are  used  on  civil  transport  aircraft." 

Sounding  the  alarm,  the  editorial  in  the  same  January  3,  1994,  issue 
of  Aviation  Week  &  Space  Technology  said,  "Human  error  is  the  cause 
of  the  vast  majority  of  civil  aircraft  accidents....  Getting  the  man- 
machine  interface  right  is  becoming  more  challenging  as  aircraft  design¬ 
ers  decide  how  many  functions  to  automate  and  how  to  keep  the  pilot 
in  the  loop."  The  Federal  Aviation  Administration’s  chief  human  fac¬ 
tors  engineer,  Mark  Hofmann,  confirmed  this  concern  in  his  January 
31,  1994,  letter  to  the  editor  of  Aviation  Week  &  Space  Technology, 
saying,  "one  major  concern  relates  to  deciding  what  aviation  tasks  and 
functions  now  being  performed  by  humans  should  be  automated.  Such 
decisions  should  be  based  on  enhancing  overall  system  performance  and 
helping  the  human  to  be  more  accurate  and  productive.  Another  concern 
is  the  availability  and  use  of  information  by  operators  and  maintainers 
due  to  the  overwhelming  pace  and  volume  of  data  flow."  The  poignant 
eoekpit  voice  recording  of  the  last  two  minutes  of  the  fatal  China  Air¬ 
lines  Flight  140  transcribed  in  the  May  23,  1994,  issue  of  Aviation 
Week  &  Space  Technology  provides  a  clear  statement  of  the  problem: 
"...  the  crew  was  making  deeisions  that  ran  eontrary  to  the  reasoning  of 
the  aircraft  system's  automated  logie."  MeDaniel  (1988)  cites  other 
automation-related  air  disasters  and  elaborates  on  how  these  relate  to 
allocation  of  functions  and  automation. 

Many  believe  effective  function  allocation  is  the  key  proeess  that  has 
the  greatest  potential  for  solving  these  types  of  problems.  Every  level 
of  the  military’s  system  acquisition  process  references  function  analy¬ 
sis/allocation.  The  different  levels  in  the  system  acquisition  chain  make 
different  uses  of  function  analysis/allocation,  however,  and  have  cus¬ 
tomized  the  definition  of  function  allocation  for  their  own  purposes. 
This  paper  reviews  function  allocation  from  the  perspective  of  different 
levels,  from  top-level  management  in  the  US  Department  of  Defense 
(DoD)  down  to  the  human  factors  engineers  who  support  the  program 
and  laboratory  scientists  and  engineers  who  develop  new  design  aids. 
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The  top-level  model  of  how  the  US  DoD  and  the  US  Air  Force  manage 
system  acquisition  includes  function  allocation  as  a  means  for  selecting 
technologies  that  can  be  implemented  to  satisfy  overall  systcni-lcvcl 
requirements.  At  the  bottom  of  the  acquisition  pyramid,  the  human 
factors  engineers  supporting  the  development  programs  think  of  func¬ 
tion  allocation  as  a  prcKcss  for  assigning  functions  or  subfunctions  to 
automation  or  a  human  operator. 

Today,  multifunction  controls  and  displays,  multiple  interconnected 
processors,  and  the  need  for  a  truly  integrated  crew  system  create  engi¬ 
neering  demands  that  arc  not  being  met  effectively.  Automation  is  often 
recommended  as  the  solution  to  operator  workload  problems,  but  we  iut 
beginning  to  realize  that  problems  with  inconsistent  implementation  of 
automation  arc  emerging  as  the  most  signiHeant  human  factors  engi¬ 
neering  nightmare.  Traditional  human  factors  engineering  t(K)Is,  such  as 
the  paper  functional  block  diagram,  arc  not  able  to  deal  with  the  multi¬ 
level  complexity  in  the  human-system  interface.  Mcxlem  crew  system 
design  is  a  complex  issue  that  should  not  be  ixldrcsscd  piecemeal  but 
requires  an  integrated  prcKCSS  and  design  support  system  to  help  manage 
the  prrKCSS.  Improved  function  allocation  techniques  arc  ncce.s.sary  to 
efficiently  guide  the  automation  of  crew  system  functions.  New  ap¬ 
proaches  to  crew  system  design  include  computer  tools  to  assist  in  the 
function  allocation  process  and  to  relate  function  allocation  to  analysis 
of  taskload  and  workload  in  complex  systems.  Some  aspects  of  acquisi¬ 
tion  appear  to  be  working  against  effective  integration  of  the  crew  sys¬ 
tem.  An  analysis  of  cockpit  design  prcKcdurcs  in  current  use  for  mili¬ 
tary  aircraft  revealed  that  the  aviation  industry's  ccK'kpit  design  prtKcss 
was  fragmented  acro.ss  departments,  primarily  according  to  the  cost  cen¬ 
ters  associated  with  the  Work  Breakdown  Structure  (WBS)  and,  sec¬ 
ondly,  according  to  the  components  acquired  directly  by  the  government 
on  othei' contracts  and  provided  to  the  prime  contractor  as  a  component 
of  the  new  system. 


TOP  MANACJKMENT  VIEW 
OF  FUNCTION  ALLOCATION 

Military  system  planners  think  of  design  and  function  allocation  as  a 
process  to  select  a  capability  that  best  meets  the  needs  of  a  .system. 
Acquisition  is  the  term  the  military  uses  to  tiescribe  the  process  for 
developing  and  obtaining  new  systems.  Acquisition  is  dellnetl  as  "a 
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directed  funded  effort  that  is  designed  to  provide  a  new  or  improved  ma¬ 
terial  capability  in  response  to  a  validated  need/’  (US  Dept,  of  Defense 
[DoD],  Directive  5000.1,  Defense  Acquisition,  February  1991).  This 
same  document  describes  a  weapon  system  as  ’’the  prime  operating 
equipment  and  all  of  the  anc'iWavy  functions  that  comprise  the  mainte¬ 
nance  capability,  training,  technical  orders,  facilities,  supplies,  spares, 
manpower,  and  anything  else  needed  to  provide  an  operational  capabil¬ 
ity."  Because  modern  weapon  systems  are  complex  beyond  comprehen¬ 
sion,  the  military's  system  acquisition  process  is  almost  as  complex, 
requiring  documents  of  hundreds  of  pages  to  fully  describe  it.  Within 
the  context  of  system  acquisition,  systems  engineering  is  the  term  used 
to  describe  managing  a  development. 

MIL-STD-499B,  Systems  Engineering  (US  DoD,  July  1994,  for¬ 
merly  titled  Engineering  Management),  defines  systems  engineering 
as:  "an  interdisciplinary  approach  to  evolve  and  verify  an  integrated  and 
lifc-eycle  balanced  set  of  system  product  and  process  solutions  that  sat¬ 
isfy  customer  needs.  Systems  engineering  (a)  encompasses  the  scientific 
and  engineering  efforts  related  to  the  development,  manufacturing,  veri¬ 
fication,  deployment,  of)erations,  support,  and  disposal  of  system  prod¬ 
ucts  and  processes,  (b)  develops  needed  user  training  equipment,  proce¬ 
dures,  and  data,  (c)  establishes  and  maintains  configuration  management 
of  the  system,  (d)  develops  work  breakdown  structures  and  statements  of 
work,  and  (e)  provides  information  for  management  decision  making." 

The  military's  model  process  for  systems  engineering  is  shown  in 
Figure  5.1. 

From  the  viewpoint  of  top  management,  function  analysis/allocation 
is  not  defined  in  terms  of  allocating  functions  to  operators  or  automa¬ 
tion.  Raihcr,  function  analysis/allocation  is  a  top-down  approach  that 
decomposes  function  requirements  to  ever  lower  levels  of  detail — -that 
is,  a  flow-down  of  requirements — until  synthesis  of  solutions  can  oc¬ 
cur.  Once  functions  have  been  decomposed  to  lower  levels,  requirements 
are  allocated  to  proposed  configuration  items  (a  term  used  to  describe 
the  low-level  products  in  the  WBS).  The  government  model  for  systems 
engineering  intentionally  avoids  terms  that  involve  uncertainty,  such  as 
"innovation,  creativity,  or  invention."  Creativity  and  invention  are  as¬ 
sumed  to  occur  within  industry.  The  management  process  involves 
trade-offs  among  alternatives  and  selection  of  the  approach  that  best 


Figure  5.1.  The  systems  engineering  process. 
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meets  the  requirements.  The  block  titled  “System  analysis  and  control” 
refers  to  progress,  cost,  and  schedule  audits. 

Synthesis  is  defined  as  the  translation  of  functions  and  requirements 
into  possible  solutions.  Synthesis  is  as  close  as  the  process  comes  to 
referencing  innovation.  Synthesis  is  conducted  iteratively  (the  “Design 
loop”  in  Figure  5.1)  with  functional  analysis/allocation  to  define  a 
complete  set  of  functional  and  performance  requirements  necessary  for 
the  level  of  the  design  output  required  and  with  requirements  analysis  to 
verify  that  solution  outputs  can  satisfy  customer  input  requirements. 

The  iterative  design  loop  includes  the  crew  system,  but  it  is  generic 
and  relates  to  all  system-level  requirements.  “Turning  the  crank”  is  the 
phrase  one  often  hears  used  to  refer  to  the  process  of  making  this  design 
loop  generate  the  design  alternatives  and  compare  them  with  require¬ 
ments.  When  the  crank  is  turned,  alternatives  are  generated,  evaluated, 
and  finally  accepted  or  rejected  based  on  formal  and  structured  criteria 
derived  from  requirements. 

CREW  SYSTEM  DESIGN  VERSUS 
THE  WORK  BREAKDOWN  STRUCTURE 

One  of  the  greatest  impediments  to  integrating  crew  system  functions 
may  be  the  WBS  for  aircraft  systems  in  the  military  standard  Work 
Breakdown  Structure  for  Defense  Materiel  Items,  MIDSTD^SSIB 
(US  DoD,  March  25,  1993).  The  WBS  is  prescribed  for  use  on  new 
system  acquisitions  to  aid  definition,  analysis,  tracking,  and  control  of 
each  component  of  the  system  throughout  the  development  period.  The 
WBS  is  a  hierarchical  diagram  that  decomposes  the  entire  system  into 
components,  subcomponents,  subsubcomponents,  etc.,  down  to  the 
level  of  each  module  of  hardware,  software,  services,  data,  training, 
support  equipment,  management,  and  other  work  tasks.  The  WBS  struc¬ 
ture,  in  use  since  the  early  1970s,  has  not  evolved  with  hardware  and 
software  technology  and  has  yet  to  recognize  the  crew  system  as  an 
important  component  of  an  aircraft. 

The  military's  solicitation  for  a  new  system  includes  the  first  three 
levels  of  the  WBS  hierarchy,  as  tailored  from  a  model  prescribed  in 
MIL-STD-881B.  In  the  Jargon  of  standards,  "tailoring"  usually  means 
deleting  nonapplicable  material,  but  not  adding  material.  As  part  of 
their  proposals,  contractors  expand  the  WBS  by  developing  the  lower 
levels  of  the  WBS  hienirchy.  The  total  WBS  becomes  part  of  the  con- 
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tract  and  directs  the  prosecution  of  the  program  from  that  time  onward. 
In  the  WBS  model  for  an  aircraft,  level  1  has  but  a  single  element,  the 
entire  aircraft  system;  level  2  has  ten  elements:  air  vehicle,  systems 
engineering/program  management,  system  test  and  evaluation,  training, 
data,  peculiar  support  equipment,  common  support  equipment,  opera¬ 
tional/site  activation,  industrial  facilities,  and  initial  spares/repair  parts. 
The  air  vehicle  is  subdivided  into  level-3  elements,  including  the  air¬ 
frame,  propulsion,  software,  etc. 

The  WBS  provides  a  consistent  mechanism  for  tracking  all  the  sub¬ 
contracts  and  vendors  contributing  to  the  system.  Its  most  important 
function  is  in  tracking  the  cost  and  progress  of  each  element,  providing 
baseline  data  for  estimating  what  the  elements  should  cost  and  how 
long  the  development  should  take.  The  WBS,  or  something  like  it,  is 
essential  to  managing  the  development  of  a  major  system.  By  assuming 
an  obsolete  structure  of  design  priorities,  however,  the  WBS  uninten¬ 
tionally  hinders  effective  function  allocation.  The  problem  is  that  the 
crew  system  is  not  defined  as  an  identifiable  component  of  the  aircraft 
in  the  WBS,  but  is  scattered  among  twelve  of  the  seventeen  level-3 
elements  under  the  level-2  air  vehicle  WBS  element. 

Below  are  excerpts  of  these  from  MIL-STD-88IB  (condensed  and  ed¬ 
ited  for  clarity): 

''Level  3  Airframe  includes  support  subsystems  essential  to  the  des¬ 
ignated  mission  requirements,  manual  flight  control  system,  fuel  man¬ 
agement  system,  furnishings  (i.e.,  crew,  cargo,  passenger,  troop,  etc.), 
instruments  (i.e.,  flight,  navigation,  engine,  etc.),  life  support  and  per¬ 
sonal  equipment. 

"Level  3  Propulsion  includes  engine  control  units,  if  furnished  as  an 
integral  part  of  the  propulsion  unit. 

"Level  3  Air  Vehicle  Applications  Software  includes  all  the  software 
that  is  specifically  produced  for  the  functional  use  of  a  computer  system 
or  multiplex  data  base  in  the  air  vehicle. 

"Level  3  Air  Vehicle  System  Software  includes  software  for  specific 
computer  system  or  family  of  computer  systems  to  facilitate  the  opera¬ 
tion  and  maintenance  of  the  computer  system  and  associated  programs 
for  the  air  vehicle. 

"Level  3  Communications/Identification  refers  to  that  equipment 
(hardware/software)  installed  in  the  air  vehicle  for  communications  and 
identification  purposes.  It  includes,  for  example,  intercoms,  radio  sys- 


88 


Improving  Function  Allocation 


tem(s),  friendor-foe  identification  equipment,  data  links,  and  control 
boxes  associated  with  the  specific  equipment 

''Level  3  Navigation/Guidance  refers  to  that  equipment  (hardware/ 
software)  installed  in  the  air  vehicle  to  perform  the  navigational  guid¬ 
ance  function.  This  element  includes,  for  example,  radar,  radio,  or  other 
essential  navigation  equipment,  radar  altimeter,  direction  finding  set, 
Doppler  compass,  computer,  and  other  equipment  homogeneous  to  the 
navigation/guidance  function. 

"Level  3  Central  Computer  refers  to  the  master  data-processing 
unit(s)  responsible  for  coordinating  and  directing  the  major  avionic  mis¬ 
sion  systems. 

"Level  3  Fire  Control  refers  to  that  equipment  (hardware/software) 
installed  in  the  air  vehicle  which  provides  the  intelligence  necessary  for 
weapons  delivery  such  as  bombing,  launching,  and  firing.  This  element 
includes,  for  example,  dedicated  displays,  scopes,  or  sights;  and  bomb¬ 
ing  computer  and  control  and  safety  devices. 

"Level  3  Data  Display  and  Controls  refers  to  that  equipment 
(hardware/software)  which  provides  visual  presentation  of  processed  data 
by  specially  designed  electronic  devices  through  interconnection  (on  or 
off  line)  with  computer  or  component  equipment,  and  associated  equip¬ 
ment  needed  to  control  the  presentation  of  data.  This  element  provides 
the  necessary  flight  and  tactical  information  to  the  crew  for  efficient 
management  of  the  aircraft  during  all  segments  of  the  mission  profile 
under  day  and  night  all-weather  conditions.  Excluded  are  indica¬ 
tors/instruments  not  controlled  by  keyboard  via  the  multiplex  data  bus 
and  panels  and  consoles  that  are  included  under  the  airframe. 

"Level  3  Survivability  refers  to  that  equipment  (hardwane/software) 
which  assists  in  penetration  for  mission  for  ferret  and  search  receivers, 
warning  devices,  and  other  electronic  devices,  electronic  countermea¬ 
sures,  Jamming  transmitters,  chaff,  infrared  jammers,  terrain-following 
radar,  and  other  devices  typical  of  this  mission  function. 

"Level  3  Reconnaissance  refers  to  that  equipment 
(hardware/software)  for  photographic,  electronic,  infrared,  and  other  sen¬ 
sors;  search  receivers;  recorders;  warning  devices;  magazines;  and  data 
link. 

"Level  3  Automatic  Flight  Control  refers  to  those  electronic  devices 
and  sensors  which  enable  the  crew  to  control  the  flight  path  of  the  air¬ 
craft  as  well  as  to  provide  lift,  drag,  trim,  or  conversion  effects.  This 
element  includes  flight  control  computers,  software,  signal  processors. 
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and  data  transmitting  elements  that  are  devoiai  to  processing  data  lor 
either  primary  or  automatic  llight  control  liinctions/’ 

The  dispersion  ol  crew  system  design  Functions  across  these  elements 
has  a  signillcanee  that  reaches  Tar  beyond  cost  aecounting.  The  WBS 
itself  allocates  design  requirements  to  specifie  organizations  responsible 
lor  their  development.  In  praetice,  the  WBS  has  influenced  the  organiza¬ 
tional  structure  of  both  the  military  program  and  the  contractor.  Re¬ 
sponding  to  the  prixluct  structure  in  the  WBS,  industry  has  organized 
into  departments  that  correspond  to  each  of  these  products,  with  a  sepa¬ 
rate  department  head  responsible  to  the  contractor’s  program  manager  for 
those  specifie  products. 

Since  the  WBS  model  has  no  clement  for  crew  system,  industry  has 
no  department  head  responsible  lor  the  crew  system.  Because  of  this 
structure,  crew  system  integration  requires  coordination  between  several 
departments  within  the  company.  Integration  is  further  hindered  because 
many  of  the  WBS  elements  are  subcontracted  out  to  other  companies, 
with  the  prime  contractor  serving  as  the  sole  coordinating  agent.  Deci¬ 
sions  made  within  individual  departments  can  adversely  effect  the  crew 
system  function  allocation  without  other  departments’  being  aware  of  a 
problem  until  it  is  loo  late  to  correct  it. 

So  far,  allcmpls  to  modify  the  standard  to  consolidate  and  integrate 
the  crew  system  into  a  single  levcl-3  WBS  clement  have  failed.  As  far 
back  as  May  1987,  a  iriscrvicc  laboratory  study  panel  proposed  a  change 
to  MIL-STD-88IA  (the  version  of  the  standard  preceding  MIL-STD- 
88 IB)  to  a  group  of  Iriscrvicc  aeronautical  commanders.  While  the 
commanders  supported  this  proposal,  it  was  subsequently  killed  by  the 
cost -accounting  officials  who  control  the  standard  on  the  grounds  that  it 
would  ruin  their  traceability  and  prediction  models.  This  is  a  major 
change,  for  it  involves  more  than  adding  a  new  clement  called  ’’crew 
system";  it  also  involves  removing  those  functions  from  the  existing 
twelve  elements.  This  proposal  would  cause  a  significant  reorganization 
of  industry,  removing  some  of  the  traditional  responsibilities  from 
ihc.sc  department  managers. 

While  the  WBS  is  unquestionably  neecssary  for  developing  new  sys¬ 
tems,  the  hierarchical  structure  has  not  evolved  to  rcficct  adequately  the 
way  in  which  modern  technology  has  changed  the  nature  of  the  aircraft. 
When  the  WBS  process  began  hack  in  the  early  I97()s,  the  pilot’s  crew 
station  was  com[K)sed  of  several  independent  subsystems,  usually  sup¬ 
plied  hy  dil  ferenl  suhcontraclors.  Then,  it  was  the  prime  contractor’s  job 
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to  locale  each  of  these  subsystems  in  the  aircraft.  In  the  context  of  the 
cockpit  design,  the  prime  contractor’s  effort  centered  on  the  cockpit  lay¬ 
out  and  installation  of  controls  and  display.s,  with  less  attention  to  func¬ 
tionality.  The  traditional  ccKkpit  design  was  a  drawing  of  a  cockpit 
showing  the  location  of  the  seal,  control  panels,  controls,  and  displays. 
The  ccK'kpit  drawings  showed  the  sizes,  shapes,  and  even  labels  for 
every  control  and  display.  This  one  drawing  could  depict  the  entire  hu¬ 
man-system  interface.  The  infonnalion  interface  was  explicit  in  the 
labeling  of  the  controls  and  mechanical  displays.  Even  the  workload 
evaluations  of  that  era  were  based  on  hand-travel  and  eye-travel  dis¬ 
tances,  rather  than  the  mental  difficulty  of  the  task. 

Modem  cockpits  have  an  almost  generic  physical  appearance,  clean 
and  uncluttered,  consisting  of  a  few  multifunction  controls  and  a  few 
multifunction  di.splays  (CRTs,  LCDs,  or  similar),  T(xlay,  the  critical 
design  issues  in  the  aircraft  cockpit  relate  to  information  management 
and  integration  of  data.  Because  of  the  massive  amount  of  infomiation 
Bowing  through  the  crew  system,  function  analysis/allocalion  is  critical 
to  the  effective  integration  of  the  modern  cockpit.  The  pilots'  demands 
for  more  situation  awareness  arc  eagerly  met  hy  new  technology  that 
can  layer  more  and  more  data  on  the  multifunction  displays,  so  that 
merely  accessing  the  data  has  become  a  time-consuming  and  complex 
task  in  itself.  As  a  result,  pilot  workload  has  increased. 

GENERAL  REQUIREMENTS  FOR 
FUNCTION  ANALYSIS/ALLOCATION 

The  US  Army,  Navy,  and  Air  Force  jointly  developed  MIL-STD- 
46H55,  Hunmn  Factors  Engineering  Requirements  for  Military  Sys¬ 
tems,  Equipment  and  Facilities  (US  DoD,  May  26,  1994),  as  the  pri¬ 
mary  human  factors  engineering  tasking  document  for  the  three  serv¬ 
ices.  In  use  since  January  1979,  this  general-purpose  standard 
establishes  and  defines  the  requirements  for  applying  human  work  to  be 
followed  hy  a  contractor  or  subcontractor.  Tailoring  and  citing  this 
document  in  a  contract  is  the  primary  way  the  military  tells  the  contrac¬ 
tor  how  much  and  what  kind  of  human  factors  engineering  effort  is  ex¬ 
pected.  The  process  of  function  analysis/allocation  is  the  heart  of  MIL- 
STD-46855,  as  demonstrated  hy  the  following  excerpts  (paragraph 
numbers  omitted,  italics  added): 
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** Defining  and  Allocating  System  Functions.  The  functions  that 
must  be  perlbmied  by  the  system  in  achieving  its  objcctive(s)  within 
specilied  mission  environments  shall  be  analyzed.  Human  Factors  engi¬ 
neering  principles  and  criteria  shall  be  applied  to  spccil'y  human-system 
lierlormance  requirements  Tor  system  operation,  maintenance  and  control 
functions  and  to  allocate  system  functions  to  ( I )  automated  opera- 
tion/maintcnancc,  (2)  manual  operation/  maintenance,  or  (3)  some 
combination  thereof.  Function  allocation  is  an  iterative  prtKcss  achiev¬ 
ing  the  level  of  detail  appropriate  for  the  level  of  system  dctlnition. 

'Information  Flow  and  Processing  Analysis.  Analyses  shall  be  per- 
foniied  to  detennine  basic  information  ilow  and  processing  required  to 
accomplish  the  system  objective  and  include  decisions  and  operations 
without  reference  to  any  specillc  machine  implementation  or  level  ol 
human  involvement. 

"Estimates  of  Potential  Operator/Maintainer  Processing  Capabili¬ 
ties.  Plausible  human  roles  (c.g.,  operator,  maintaincr,  programmer, 
decision  maker,  communicator,  monitor)  in  the  system  shall  be  identi¬ 
fied.  Estimates  of  processing  capability  in  terms  of  workload,  accuracy, 
rate,  and  lime  delay  should  be  prepared  for  each  potential  opera- 
lor/mainlaincr  information  pnKcss'mg  function.  Comparable  estimates 
of  equipment  capability  shall  also  be  made.  These  estimates  shall  be 
used  initially  in  determining  allocation  of  functions  and  shall  later  be 
refined  at  appropriate  times  for  use  in  definition  of  opcrator/mainlaincr 
information  requirements  and  control,  display  and  communication  re¬ 
quirements.  In  addition,  estimates  shall  be  made  of  the  effects  on  these 
capabilities  likely  to  result  from  implementation  or  non- 
implementation  of  human  factors  engineering  design  recommendations. 
Results  from  studies  in  accordance  with  5.2.1  may  be  used  as  suppor¬ 
tive  inputs  for  these  estimates. 

"Allocation  of  Functions.  From  projected  opcrator/mainlaincr  per¬ 
formance  data,  c.sli mated  cost  data,  and  known  constraints,  analyses  :uid 
trade  off  studies  shall  be  conducted  to  determine  which  system  functions 
should  be  machine-implemented  or  software  controlled  and  which 
should  be  reserved  for  the  human  operalor/maintaincr.  Allocation  of 
functions  shall  consider  the  risks  of  making  an  incorrect  decision  for 
each  alternative  being  evaluated  so  that  designs  may  be  simplified  or 
enhanced  to  prevent  or  minimi/e  situations  where  human  decisions  luv 
made  under  conditions  of  uncertainty,  lime  stress,  or  workload  stress. 
The  possibility  of  influencing  human  or  c(|uipmenl  capabilities  through 
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personnel  selection  and  training  as  well  as  through  equipment  and  pro¬ 
cedure  design  shall  be  considered,  and  the  costs  of  such  action  shall  he 
considered  in  trade-off  and  cost-hcncfit  studies.” 

MIL-STD-46855  uses  the  same  functional  hierarchy  dcllncd  in  sev¬ 
eral  triscrvicc  standards,  MIL-STD-I9()8,  Definitions  of  Human  Factors 
Terms  (US  DoD,  December  24,  1992),  MIL-STD-I388HA,  Logistic 
Support  Analysis  (US  DoD,  April  11,  1983),  and  the  Army’s  MIL- 
STD- 1 478,  Task  Performance  Analysis  (US  DoD,  May  13,  1991). 
Figure  5.2  shows  this  hierarchy  compared  to  the  one  typically  used  in 
crew  system  design.  The  Logistics  Support  Analysis  computes  the  re¬ 
quirements  for  MPT  (manpower,  or  the  number  of  people;  personnel, 
the  job  titles;  and  training),  hence  the  inclusion  of  the  items  “Joh”  and 
“Duty.”  While  they  have  similar  names,  this  hierarchy  differs  from  the 
hierarchy  used  in  aircraft  development  dc.scribcd  below.  The  triscrvicc 
term  “Joh,”  for  example,  would  refer  to  a  pilot,  and  “Duty”  would  refer 
to  Hying  the  aircraft. 

In  the  general-purpose  hierarchy,  “Mission,”  “Scenario,”  and 
“Function”  arc  major  command  functions  and  do  not  correspond  to  any 
terms  used  in  crew  system  development.  The  lower-level  terms,  “Task,” 
“Suhtask,”  and  “Task  element”  in  the  MJL-STD-46855  structure  arc 
similar  to  “Function,”  “Suhfunction,”  and  “Task”  dcilnitions  of  the 
aircraft  development  structure. 

AIR  FORCE  IMPLEMENTATION 
OF  FUNCTION  ALLOCATION 

While  the  triscrvicc  MIL-STD-46855  was  designed  to  he  generic  and 
applicable  to  all  systems,  the  Air  Force  has  developed  its  own  special- 
purpose  standard  tailored  to  the  supercritical  needs  of  the  aircraft  crcw 
system:  MIL-STD-I776A,  Aircrew  Station  and  Passenger  Accommo¬ 
dations  (US  DoD,  February  25,  1994).  Section  4.1  of  this  document 
contains  a  Crew  System  Development  Process  (CSDP),  which  is  tai¬ 
lored  for  complicated  aircraft  cockpits.  The  application  guidance  for  the 
procc.ss  notes  (italics  acJdcd):  "It  is  recognized  that  dc.signs  do  not  .start 
from  'scratch’  hut  that  a  baseline  (or  similar)  system  is  typically  used 
from  which  to  make  improvements.  The  function  analysis  analyzes  the 
events  identified  in  the  mission  analysis  and  defines  functions  that  the 
aircraft  system  has  to  |x:rform  in  order  to  complete  the  mission.  The 
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functions  arc  then  allocated  to  be  performed  by  the  aircrew  or  other 
subsystems  within  the  aircraft....  Included  in  {he  function  allocation 
process  is  the  analysis  of  the  information  requirements  of  the  aircrew  in 
order  to  complete  the  mission.  Control  and  display  parameters  arc  then 
identified  to  provide  adequate  information  transmission  between  the 
aircrew  and  aircraft  in  order  for  the  aircrew  to  perform  the  functions  al¬ 
located  to  the  aircrew  subsystem.  Based  on  these  parameters,  and  the 
rest  of  the  aircrew  system  implementation,  task  load,  and  workload  for  a 
given  aircrew  station  can  be  analyzed.” 

This  process  calls  for  verifying  the  effectiveness  of  the  design  by 
'‘reviewing  the  analyses  as  they  arc  developed,  observing  the  mock-up 
and  simulation  demonstrations,  and  reviewing  simulation  test  plans  and 
results."  The  process  also  requires  the  generation  and  submission  of 
reports  in  the  formats  specified  in  MIL-STD-46855. 

Section  4.1.3  of  MIL-STD- I776A  has  detailed  requirements  for  func¬ 
tion  allocation:  "Functions  allocated  to  the  aircrew  shall  identify 
which  aircrew  member  ix^rfonns  ihni  function.  For  functions  assigned 
jointly  to  the  aircrew  and  another  aircraft  subsystem  and/or  to  more  than 
one  aircrew  member,  the  subsystem  or  aircrew  member  which  has  pri¬ 
mary  responsibility  for  performing  the  function  and  the  subsystem  or 
aircrew  member  which  has  secondary  responsibility  for  performing  the 
function  shall  be  idcniificd.  Functions  may  be  allocated  to  more  than 
one  type  of  implementation.  Functions  may  also  be  allocated  to  more 
than  one  subsystem.”  For  practicality,  it  is  also  recognized  that 
"program  schedule  and  rc.source  constraints  restrict  designers  to  analyze 
only  the  problem  areas  perceived  to  be  the  most  difficult."  To  conserve 
rc.sourccs,  new  function  analyses  often  use  segments  of  old  function 
analyses  from  the  baseline  system  to  fill  in  the  gaps  between  the  new, 
critical,  or  difficult  functions  of  the  new  design.  In  many  eases,  func¬ 
tions  in  new  systems  arc  allocated  as  they  were  in  the  baseline  system, 
particularly  if  the  hasclinc  functions  were  free  of  problems.  Appendix  C 
of  MIL-STD- I776A  contains  a  thirty-page  instruction  for  integrating 
the  CSDP  into  the  Systems  Engineering  Master  Plan  (SEMP)  and  Sys¬ 
tems  Engineering  Master  Schedule  (SEMS),  which  integrate  all  devel¬ 
opment  activities.  This  process  emphasizes  the  integrated  prcxluct  team 
(IPT)  approach  and  describes  how  the  various  teams  interact  to  c(X)rdi- 
natc  the  entire  system. 
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SYSTEM  DEVELOPER’S  VIEW 
OF  FUNCTION  ALLOCATION 

When  the  Air  Force  begins  to  acquire  a  new  aircraft  or  make  a  major 
modification  to  an  existing  aircraft,  a  system  program  office  (SPO)  is 
established  by  bringing  members  of  various  disciplines  together  as  a 
team.  These  SPOs  are  located  at  Wright-Patterson  Air  Force  Base  to  be 
near  the  research  and  development  expertise  centered  in  the  laboratories 
also  located  there.  This  SPO  team  translates  the  operational  require¬ 
ments  into  a  contract  and  later  manages  that  contract.  Typically,  the  Air 
Force  contracts  with  industry  for  aircraft  design  and  production.  Simi¬ 
larly,  the  engineering  part  of  function  analysis/allocation  is  contracted 
to  industry  as  part  of  the  overall  system  development.  The  official  in¬ 
volvement  of  military  personnel  in  the  process  is  to  monitor  industry's 
efforts. 

The  contract  tasks  industry  to  perform  function  analysis/allocation  in 
one  of  two  ways.  The  first  way  is  by  requiring  the  contractor  to  perform 
a  human  factors  engineering  program  in  accordance  with  MIL-STD- 
46855  and/or  M1L’STD’1776A,  both  of  which  include  instructions  for 
performing  function  analysis/allocation.  The  second  method  is  to  insert 
specific  requirements  for  performing  function  analysis/allocation  into 
the  contract  Statement  of  Work.  Either  way,  the  military  (program  offi¬ 
cials  from  the  SPO  and  pilots  from  the  using  command)  participate  by 
reviewing  the  contractor's  products  at  design  reviews,  attending  mock- 
up  reviews,  and  observing  simulations  of  the  crew  system.  The  format 
and  contents  of  the  function  analysis/allocation  vary  from  one  company 
to  another,  and  its  quality  depends  largely  on  the  expertise  of  company 
engineers  and  the  resources  available  for  the  effort.  The  function  analy¬ 
sis/allocation  is  not  an  end  in  itself,  but  a  means  to  acquiring  an  effec¬ 
tive  and  efficient  system. 

To  implement  the  IPT  approach  to  system  development,  the  Air 
Force's  on-going  F-22  program  has  made  a  radical  departure  from  the 
WBS  model  in  MIL-STD-SSL  Using  its  prerogative  to  “tailori’  the 
model  WBS,  the  F-22  SPO  completely  overhauled  it  and  made  the 
“cockpit  system  IPT“  one  of  eight  level-3  elements  in  the  WBS  (one 
element  for  each  of  the  eight  IPTs).  The  cockpit  system  element  is  sub¬ 
divided  into  five  subelements:  pilot-vehicle  interface  (PVI),  aircrew  sta¬ 
tion  accommodations,  escape,  life  support,  and  canopy.  The  F-22  pro¬ 
gram  did  not  make  a  total  break  with  the  traditional  WBS  model. 
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however,  for  another  level-3  element  is  avionics,  which  contains  the 
avionics  controls  and  displays  hardware.  Notwithstanding  this  excep¬ 
tion,  the  F-22  program  is  the  first  military  program  to  experiment  with 
such  a  high  level  of  integration  of  the  crew  system  design  activities. 
The  results  to  date  indicate  this  approach  to  be  far  superior  to  the  tradi¬ 
tional  WBS,  providing  high  visibility  to  crew  system  issues  and  get¬ 
ting  problems  resolved  in  favor  of  the  pilot. 

The  specific  definition  of  the  cockpit  system  element  used  by  the 
F-22  program  is  as  follows:  "This  element  comprises  the  systems  and 
equipment  that  provide  the  pilot  the  capability  to  manage  the  aircraft 
subsystems  and  to  function  within  the  aircraft  performance  and  threat 
envelope.  This  includes  the  pilot-vehicle  interface,  crew  station  design, 
life  support,  escape  systems  and  human  engineering/crew  vehicle  inter¬ 
face  (CVI),  and  the  canopy  system.  This  element  includes  the  coordin¬ 
ated  functional  efforts  of  the  Cockpit  Integrated  Product  Team  associated 
with  the  task  for  each  of  the  subelements  listed  above,  including  the 
tasks  related  to  analysis,  design,  development,  test,  qualification,  fabri¬ 
cation,  assembly,  installation,  integration,  verification,  and  documenta¬ 
tion.  Included  as  part  of  each  subelement  is  the  application  of  human 
engineering  principles  in  the  design  and  development  process." 

The  function  analysis/allocation  process  provides  the  key  for  military 
and  industry  personnel  to  develop  better  crew  systems.  Acquisition 
regulations  that  prohibit  military  personnel  from  directing,  managing, 
or  supervising  contractors  create  a  barrier  to  technical  discussions.  The 
requirements  included  in  the  contract's  Statement  of  Work  and  specifica¬ 
tion  are  deliberately  general  so  as  not  to  unnecessarily  hinder  the  con¬ 
tractor  from  developing  the  best  possible  product.  Within  this  context, 
the  function  analysis/allocation  provides  a  valuable  communications 
mechanism,  so  that  industry  can  get  a  better  understanding  of  how  the 
military  customer  sees  the  contractor’s  design  in  the  context  of  require¬ 
ments  and  so  that  the  military  can  get  a  better  understanding  of  just 
what  industry  is  planning  to  deliver.  The  function  analysis/allocation 
turns  out  to  be  one  of  the  most  effective  tools  for  understanding  the 
crew  system  at  a  detailed  level. 

While  most  design  and  development  work  is  done  on  contract  by  in¬ 
dustry,  there  are  occasions  when  quick  reaction  or  restricted  information 
requires  that  some  design  work,  including  function  analysis/allocation, 
be  done  in-house.  All  of  the  aircraft  SPOs  are  part  of  the  Air  Force's 
Aeronautical  System  Center  (ASC).  ASC  also  has  the  Crew  Station 
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Evaluation  Facility  (CSEF).  The  CSEF  performs  a  special  design  and 
evaluation  role  for  some  programs.  For  example,  recently,  the  CSEF 
evaluated  the  functions  of  a  KC-135  flight  deck  as  part  of  a  general  re¬ 
design  to  eliminate  the  navigator  position.  After  reallocating  the  navi¬ 
gator  functions  to  the  pilot  and  copilot,  workload  analysis  revealed  the 
need  for  automating  some  functions.  The  CSEF  developed  an  alterna¬ 
tive  design  and  configured  a  two-place  simulator  to  test  the  revised  de¬ 
sign.  The  CSEF  has  crew  system  simulators  for  several  existing  aircraft 
that  are  used  to  perform  special  studies.  Pilot-in-the-loop  simulator 
evaluation  was  then  used  to  validate  the  conceptual  design  and  demon¬ 
strate  acceptable  crew  workload.  This  proof-of-concept  became  the  foun¬ 
dation  of  requirements  documents  for  the  KC- 1 35  system  upgrade  that 
was  later  contracted  to  industry.  By  testing  certain  concepts  in-house, 
the  CSEF  helps  the  SPO  develop  more  efficient  contracts.  The  CSEF 
can  work  directly  with  other  military  personnel  as  part  of  an  integrated 
product  team,  whereas  contractors  must  be  dealt  with  at  arm’s  length 
through  advance  tasking  on  a  contract  and  redirected  only  through  a 
time-consuming,  formal  contract  change. 

LABORATORY  VIEW  OF  FUNCTION  ALLOCATION 

In  1951,  Paul  M.  Fitts,  the  founder  of  the  Human  Engineering  Divi¬ 
sion  of  the  US  Air  Force’s  Armstrong  Laboratory,  was  the  first  to  ap¬ 
ply  formal  rules  to  function  allocation  in  his  list  of  those  functions  in 
which  humans  excel  over  machines  and  those  functions  in  which  ma¬ 
chines  excel.  Today,  similar  listings  are  still  called  Fitts'  lists.  Because 
Fitts'  functions  arc  general  in  nature,  they  remain  valid,  for  the  most 
part.  One  might  argue  that  remote-sensing  technology  now  excels  at 
detecting  small  amounts  of  energy,  but  recognition  and  identification 
continue  to  be  better  done  by  humans.  The  ability  to  store  large 
amounts  of  data  now  favors  the  computer,  but  humans  arc  still  required 
to  interpret  and  understand  the  nature  of  data. 

Between  1984  and  1992,  the  Paul  M.  Fitts  Human  Engineering  Divi¬ 
sion  sponsored  a  three-phased  contract  effort  called  Cockpit  Automation 
Technology  (CAT)  that  involved  five  major  aircraft  companies 
(McDaniel,  1986;  McDaniel,  1988;  Kulwicki,  McDaniel,  &  Guadagna, 
1987).  In  the  late  1980s,  the  work  begun  with  the  CAT  effort  was  ex¬ 
tended  under  a  project  named  Crcw-Ccntered  Cockpit  Design  (CCCD) 
(Storey,  Roundtree,  Kulwicki,  &  Cohen,  1994).  CCCD  is  developing  a 
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new  and  integrated  CSDP  with  formal  procedures  and  tools  for  function 
analysis/allocation.  Importantly,  the  CSDP  methodology  is  imple¬ 
mented  with  CCCD's  computer-based  toolset  providing  support  for  the 
design  of  both  new  and  upgraded  crew  systems.  Martin  (1994)  described 
the  application  of  the  toolset  in  a  sample  FI  6  cockpit  upgrade  to  illus¬ 
trate  the  new  process. 

The  CCCD  process  currently  has  about  120  activities,  most  sup¬ 
ported  by  separate  software  design  tools.  It  is  beyond  the  scope  of  this 
paper  to  describe  all  of  them.  The  120  activities  of  the  CSDP  are  di¬ 
vided  into  five  categories:  program  planning/scheduling,  requirements 
analysis  and  predesign,  crew  system  analysis,  crew  system  design,  and 
crew  system  evaluation.  The  “crew  system  design”  category  accounts  for 
the  majority  of  the  activities.  A  key  element  in  this  toolset  is  a  struc¬ 
ture  and  discipline  to  perform  function  analysis/allocation. 

A  survey  of  industry  users  by  Lehman  et  al.  (1994)  revealed  that  the 
majority  of  aircraft  manufacturers  have  developed  their  own  rapid¬ 
prototyping  simulators  and  make  extensive  use  of  simulation  to  verify 
the  function  allocation  and  assure  that  pilot  workload  is  acceptable.  The 
weakness  of  such  simulation  is  that  the  data  are  almost  entirely  subjec¬ 
tive,  relying  on  critique  by  pilot  subjects  in  the  idealized  ground-based 
simulation.  Because  of  the  critical  role  of  the  simulation,  the  industry 
human  engineers  are  at  the  mercy  of  scarce,  highly  sophisticated  pro¬ 
grammers  as  well  as  electrical  and  hardware  engineers  to  modify  and  run 
these  simulators.  Loss  of  access  to  key  personnel  because  of  higher 
priority  projects  can  stop  an  evaluation.  To  prevent  such  limitations, 
the  CSDP  toolset  is  directly  linked  into  a  generic  crew  system  simula¬ 
tor,  called  the  Engineering  Development  Simulator  (EDSim),  which  is 
rcconfigurable  without  sophisticated  programming  support  (Givens, 
1994).  Because  the  system  is  built  with  object-oriented  software,  a 
journeyman  programmer  can  modify  or  even  create  a  new  display  for  the 
system.  The  EDSim  is  an  integral  part  of  the  CSDP  toolset,  allowing 
the  analytical  tools  and  the  EDSim  to  share  data. 

CCCD’s  CSDP  is  structured  in  accordance  with  the  general  guidelines 
in  MIL-STD~46855,  and  even  has  utilities  that  generate  reports  in  the 
format  required  by  MIL-STD-46855.  An  earlier  version  of  CCCD's 
CSDP  was  used  as  a  model  for  the  CSDP  now  included  in  MIL-STD- 
1776A,  discussed  above,  and  is  compatible  with  the  IPT  concept  of 
design  support.  The  CSDP  uses  the  aircraft  function  hierarchy  in  Figure 
5.2.  In  this  hierarchy,  functions  and  subfunctions  refer  to  activities  that 
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must  be  accomplished,  but  without  specHying  how  they  will  he  per- 
Ibrnied.  At  the  lowest  level,  after  a  function  or  subfuaetion  is  alkK'ated 
to  an  operator  or  automation  and  is  implemented  with  a  specillc  pr(K'e- 
dure  for  accomplishing  the  function,  it  hecomes  a  task. 

The  CCCD  toolset  contains  specific  aids  to  help  with  function  analy- 
sis/alloeation.  At  the  top  level,  a  Mission  Deeomposilion  Tool  assists 
in  identifying  the  top-level  functions  and  assigning  a  target  time  line. 
To  avoid  mistakes  caused  when  the  designer  assumes  the  role  of  the 
user,  a  new  Concept  Mapping  technique  allows  the  user  to  play  the  role 
of  designer  and  effeelively  inlluence  the  function  allocation  and  design 
decision  making  (MeNcese  ei  al.,  1995).  The  Time  Line  Management 
T(K)1  includes  three  modules:  the  Infonnation  and  Control  Requirements 
Analysis  Tool,  the  Function  Flow  Analysis  Tool,  and  the  Function 
Allocation  Trade  Analysis  Tool.  These  provide  input  to  taskload  and 
workload  analysis  programs. 

CONCLUSIONS  AND  RFXOMMENDATIONS 

Mission  analysis,  function  analysis,  and  function  allocation  have 
long  been  rccogni/.cd  as  necessary  to  the  design  of  complex  systems. 
Yet,  there  has  been  little  standardization  in  terminology,  and  many  peo¬ 
ple  use  the  terms  function  and  task  interchangeably.  Attempts  to  cob¬ 
ble  together  taxonomies  that  serve  both  design  and  MPT  purposes  have 
disappointed  both  camps.  At  the  crew  system  level,  functions  refer  to 
specific  activities  that  must  he  accomplished.  The  icrm  function  alloca¬ 
tion  refers  to  the  process  of  assigning  a  function  cither  to  the  opera- 
tor(s)  or  to  automation. 

Function  analysis  has  proven  useful  in  detailing  the  rcquirciucnts  for 
components  of  a  complex  system,  providing  a  common  ground  for  un¬ 
derstanding  and  communication  among  the  members  of  the  development 
team.  The  creation  of  an  unillcd  crew  system  design  team  to  addrc.ss  all 
crew  system  issues  marks  an  advance  iu  the  design  process.  Currently, 
the  Air  Fmrcc  calls  such  teams  integrated  product  teams.  The  F-22 
SPO  believes  that  IPTs  have  proved  to  be  effective,  and  their  use  will 
likely  continue  and  spread  to  other  programs. 

For  new  aircraft  systems,  piloted  simulation  continues  to  be  the  pre¬ 
ferred  method  of  testing  the  effectiveness  of  function  allocation.  Using 
simulators  for  testing  is  expensive  and  time  consuming.  In  an  attempt 
to  reduce  the  cost  of  testing  a  design  and  to  accomplish  analysis  earlier 
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in  the  design  process,  laboratory  programs  arc  attempting  to  develop 
analytical  tools  to  support  crew  system  design.  The  computer  tools  can 
share  data  where  useful  and  minimize  the  labor  of  working  with  data. 
The  difllculty  in  developing  a  computer  tool  to  automate  function  allo¬ 
cation  is  in  the  implementation  of  the  function.  The  problem  is  subtle, 
but  highly  signillcant.  The  most  fundamental  problem  with  function 
allocation  is  that  its  effectiveness  cannot  be  evaluated  at  the  conceptual 
level  of  the  function.  Analysis  can  only  be  carried  out  after  the  imple¬ 
mentation  of  the  function.  A  human  operator  and  a  machine  will  not 
perform  a  task  the  same  way  or  at  the  same  speed.  It  is  axiomatic  that 
only  implemented  functions  can  be  assigned  task  times  and  their  inter¬ 
action  with  other  functions  assessed.  Implemented  functions  should  be 
called  tasks  to  distinguish  this  characteristic. 

Previous  computer  tools  aimed  at  function  analysis  have  failed  be¬ 
cause  they  try  to  analyze  the  function  itself,  rather  than  the  implementa¬ 
tion  of  the  function  (the  task).  The  reason  implementation  of  a  function 
cannot  be  automated  is  that  it  is  a  creative  and  inventive  process  that 
involves  application  of  specific  technologies.  To  design,  after  all,  is  to 
conceive  and  plan  out  in  the  mind.  After  a  function  is  alkxatcd  to  an 
operator  or  automation,  some  creativity  is  required  to  implement  it  ef¬ 
fectively  into  a  human-system  interfaee  or  some  automated  equipment. 
In  practice,  our  inability  objectively  to  prescribe  the  creative  elements 
of  function  implementation  has  prevented  totally  automated  analysis  of 
design  candidates. 

Nor  can  function  implementation  be  superficial.  Functions  can  usu¬ 
ally  be  implemented  in  more  than  one  way,  whether  assigned  to  a  hu¬ 
man  or  to  automation.  Analysis  can  err  when  evaluating  a  sloppy  or 
half-baked  implementation.  Frequently,  when  a  new  implementation  is 
compared  to  an  old  implementation  in  a  baseline  system,  the  newly 
implemented  function  appears  more  efficient  because  some  of  the  details 
were  overlooked.  Unless  all  function  implementation  alternatives  arc 
optimized  to  the  same  degree,  there  will  be  no  equal  basis  for  compari¬ 
son.  If  functions  arc  assigned  to  and  implemented  for  a  human  operator, 
the  effectiveness  should  be  tested  by  a  person  who  has  first  learned  to 
operate  the  function  with  a  reasonable  proficiency.  In  a  complex  crew 
system,  a  function  implementation  should  not  be  evaluated  in  i.solation, 
but  in  the  context  of  the  total  crew  system  in  a  realistic  environment  to 
judge  the  interactions  of  functions. 
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THE  FUNCTION  ALLOCATION  PROCESS  AND 
MODERN  SYSTEM/SOFTWARE  ENGINEERING 

E.  Nord0  and  K.  Brathen 


In  systein/softwcire  cn^inccriti^,  function  allocatioti  is  con¬ 
sidered  an  inherent  f>art  of  desi}^n:  in  hunuin  eni^ineering,  on 
the  other  hand,  function  allocation  is  viewed  as  a  discrete 
step  in  system  development.  Simulation  of  behavior  models 
representing  alternative  allocations  is  the  most  important 
analytical  technique  used  for  function  allocation  in  system/ 
.software  engineering.  A  major  issue  affecting  the  function  al¬ 
location  process  is  the  quality  of  the  modelling  of  system  be¬ 
havior.  The  use  of  formal  languages  for  behavior  modelling 
as  well  as  object  orientation  are  increasingly  important  in 
system/software  engineering.  Certain  techniques  and  prin¬ 
ciples  used  for  software  development  are  also  relevant  for  al¬ 
location  between  human  and  machine.  It  is  suggested  that 
some  of  these  system  engineering  and  .software  engineering 
developments  should  be  considered  within  human  engineer¬ 
ing  in  order  to  advance  the  integration  of  system  develop¬ 
ment  efforts  and  to  improve  the  function  allocation  process. 


INTRODUCTION 

In  human  laclors  engineering,  funclion  alloeaiion  to  human  or  ma¬ 
chine  is  considered  a  main  step  of  system  development,  and  a  number  of 
function  allocation  lechnicjues  have  been  proposed.  The  role  of  function 
allocation  seems  to  be  much  less  pronounced  in  syslem/soriware  engi¬ 
neering,  and  function  allocation  is  usually  considered  as  an  inherent  part 
of  design.  This  paper  discus.ses  the  issue  of  allocation  in  the  system 
development  process  in  general  and  how  modern  syslem/soflware  engi- 
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nccring  practices  might  alTcct  function  allocation  within  human  factors 
engineering  in  the  future.  System  modelling  and,  in  particular,  ohjcct- 
oriented  techniques,  are  addressed.  Function  allocation  within  human 
factors  engineering  is  briclly  introduced  before  function  allocation 
within  systcm/softwarc  engineering  is  described  in  some  detail.  It  is 
concluded  that  systcm/softwarc  engineering  puts  less  emphasis  on  the 
allocation  itself  and  more  on  the  analysis  and  evaluation  of  the  alloca¬ 
tion  decisions.  For  human  factors  engineering  to  be  able  to  take  advan¬ 
tage  of  the  advances  in  modem  system/software  engineering,  an  impor¬ 
tant  issue  is  how  the  modelling  concepts  used  within  systcm/softwarc 
engineering  arc  applicable  for  modelling  of  the  complete  human- 
machine  system. 


ALLOCATION  WITHIN 
THE  SYSTEM  DEVELOPMENT  PROCESS 

A  behavior  model  of  the  system  is  the  main  result  from  the  initial 
systcm/softwarc  engineering  effort.  The  mission  and  scenario  analyses 
and  the  subsequent  function  analysis  result  in  a  description  of  the  de¬ 
sired  functional,  or  behavioral,  characteristics  of  the  propo.scd  system.  A 
function  represents  a  logical  unit  of  what  we  denote  as  the  behavior 
model.  The  term  behavior  refers  to  both  the  human  and  the  machine 
parts  of  the  system  and  is  used  in  the  systcm/softwarc  engineering  sense 
of  the  word;  that  is,  behavior  is  dcllned  by  a  system's  inputs,  outputs, 
and  states  as  a  function  of  time  according  to  certain  performance  rc- 
quirements.  Later,  we  will  discuss  necessary  ingredients  of  this  iiKxlcI 
in  the  context  of  function  allocation. 

Functional  analysis  is  concerned  with  decomposition  of  functional 
requirements  and  behavior.  In  parallel  with  the  function  analysis,  sys¬ 
tem  components  and  their  hierarchy  arc  identified  in  what  we  denote  as 
the  component  model.  In  order  to  analyze  functions  in  a  meaningful 
way,  it  is  usually  necessary  to  consider  the  main  charactcri.stics  of  these 
system  components.  A  component  is,  in  general,  an  abstract  concept, 
hut  at  a  certain  level  of  detail  will  he  associated  with  real  components. 
The  main  types  of  system  components  arc  humans  (liveware),  hardware, 
and  software. 

The  mapping  of  the  behavior  model  onto  the  component  model  is 
called  function  allocation.  This  mapping  implicitly  establishes  the 
links  between  the  components  and  the  required  behavior  of  the  inter- 
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faces.  The  main  types  of  interfaces  are  human-human,  human-machine, 
and  machine-machine.  Interface  characteristics  such  as  capacity  of  and 
delays  on  the  links  connecting  the  components  must  be  considered.  In 
practice,  function  analysis/funetion  allocation  is  iterated  until  a  real 
system  that  implements  the  required  system  behavior  is  proposed 
(Figure  6.1). 

Information-processing  capacity  of  the  components  is  limited,  and 
performance  requirements  associated  with  allocated  behavior  must  be 
checked.  Behavior  must  be  specified  in  order  to  manage  resources  in 
situations  with  both  normal  and  extreme  workload.  Various  types  of 
nonfunctional  requirements,  such  as  maintainability  and  redundancy, 
must  also  be  considered.  Components  may  fail  in  various  ways.  Thus, 
a  failure  mode  effects  analysis  must  be  performed  and  then  error  detec¬ 
tion  and  recovery  requirements  must  be  specified.  The  main  goal  of 
error  handling  is  to  return  the  system  to  its  normal  behavior.  The  sys¬ 
tems  engineer  must  be  assisted  by  component  specialist  engineers  of 
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Figure  6.1.  Combined  development  of  behavior  and  component 
model. 
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various  backgrounds  in  order  to  analyze  the  components’  functional, 
interface,  and  nonfunctional  requirements  in  detail.  Consideration  of  all 
these  requirements  makes  it  necessary  to  extend  and  refine  the  original 
behavior  model.  A  new  implementation-dependent  model  is  then  de¬ 
fined.  The  original  model  should  be  preserved,  however,  since  it  is  eas¬ 
ier  to  understand. 

The  implementation  of  the  human-machine  interface  and  the  error 
handling  at  various  levels  often  constitute  more  than  half  the  software 
development  effort.  The  fact  that  software  often  is  the  major  cost  item 
further  emphasizes  the  importance  of  analyzing  interfaces  and  nonfunc¬ 
tional  requirements.  An  important  motivation  behind  an  analytical  ap¬ 
proach  to  function  allocation  is  to  reduce  the  number  of  changes  to  im¬ 
plementation  (including  prototypes)  later  in  system  development, 
thereby  achieving  cost  savings. 

MODELLING  OF  SYSTEMS 

The  requirements  of  a  modelling  language,  in  which  the  functional 
model  is  expressed,  depend  on  the  application  domain  and  the  purpose 
of  the  modelling.  Approaches  to  modelling  can  differ  in  formality,  ab¬ 
straction,  and  perspective.  The  emphasis  may  be  on  the  information 
processing  involving  complex  data  structures  or  on  the  dynamic  aspects 
involving  control  sequences. 

The  importance  of  a  defined  syntax  for  the  modelling  language  is 
widely  recognized.  A  mutual  understanding  of  the  semantics  (meaning) 
of  the  model  among  people  (and  computers)  is  also  required.  The  need 
to  develop  formal  descriptions  is  obvious  from  the  system/software 
engineering  point  of  view,  and  the  primary  example  is,  of  course,  pro¬ 
gramming.  It  is  important  to  realize  that  a  formal  behavior  model  also 
can  be  executed  in  much  the  same  manner  as  a  program.  There  is  often 
a  conflict,  however,  between  the  desire  to  formalize  and  the  need  to  un¬ 
derstand  the  resulting  description. 

A  function  is  usually  conceived  of  as  an  information-processing  activ¬ 
ity.  At  a  certain  level  in  the  description,  we  focus  on  the  output  and  the 
required  input  and  consider  the  function  itself  as  a  black  box.  The  back¬ 
bone  of  a  behavior  model  is  a  hierarchy  of  functions  decomposed  to  a 
level  with  which  the  designer  is  satisfied  (Harel,  1992). 

Data  elements  and  stores  are  specified  and  associated  with  the  input 
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and  output  flowing  between  functions  (also  denoted  as  activities,  ac¬ 
tions,  transformations,  or  processes).  This  relationship  between  the 
functions  is  termed  data  flow  and  is  usually  depicted  in  data  flow  dia¬ 
grams.  It  is  important  to  realize  that  the  data  flow  relation  stipulates 
only  that  information  can  flow.  Additional  information  is  required  to 
describe  when  this  will  happen  and  by  whom  the  functions  arc  per¬ 
formed.  It  can  be  argued  that  the  semantics  of  functions  and  data  flows 
are  informal  and  therefore  restrict  analysis  (Brack  &  Haugen,  1993).  A 
reader  invariably  associates  sequences  of  processing  with  data  flow  dia¬ 
grams,  an  interpretation  that  is  invalid  in  principle  and,  more  impor¬ 
tantly,  is  potentially  in  conflict  with  the  understanding  of  others  in¬ 
volved  in  the  development.  Likewise,  use  of  structured  English  to 
describe  how  functions  transform  the  information  is  equally  error  prone 
without  a  rigorous  definition  of  its  semantics. 

The  (timewise)  sequential  relationships  between  functions  are  termed 
control  flow  and  are  mandatory  in  order  to  deal  with  real-time  systems. 
The  main  (or  only)  purpose  of  a  number  of  functions  will  be  to  sense  or 
control  such  dynamics.  The  function  analysis  techniques  reviewed  by 
NATO  Research  Study  Group  14  (RSG.14)  (Beevis,  1992)  focus  on 
either  the  data  flow  or  the  control  flow,  but  only  to  a  certain  degree  on 
both  these  dimensions.  In  this  paper,  we  consider  behavior  to  include 
both  data  and  control  flow.  The  human  is  viewed  as  an  event-sensitive 
information  processor.  A  complete  behavior  model  also  includes  infor¬ 
mation  flow  into  and  out  of  tasks,  and  sequencing  and  concurrency  be¬ 
tween  tasks. 

OBJECT-ORIENTED  SYSTEM/SOFTWARE  ENGINEERING 

Jobling,  Grant,  Barker,  and  Townsend  (1994)  point  out  a  major  prob¬ 
lem  with  traditional  function  decomposition.  The  decomposition  vio¬ 
lates  the  principle  of  dynamic  system  decomposition  by  attempting  to 
model  a  dynamic  system  with  a  hierarchy  of  stateless  functions  and  a 
global  state  reservoir  from  which  any  function  may  draw  its  inputs  and 
into  which  it  may  deposit  its  outputs.  That  is,  state  and  behavior  arc 
not  preserved  within  the  boundary  of  the  decomposed  functions.  In  ob¬ 
ject-oriented  system/software  engineering,  this  problem  is  addressed  in  a 
way  that  is  more  in  accordance  with  a  control  engineering  view  of  a 
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dynamic  system.  Other  drawbacks  of  functional  decomposition  are  the 
lack  of  support  for  instantiation  and  reuse  of  function  types,  which  are 
concepts  considered  fundamental  in  object-oriented  analysis  and  design. 

The  use  of  an  object-oriented  approach  is  currently  expanding  upwards 
into  design  and  analysis  (Goad  &  Yourdon,  1991;  Rumbaugh,  Blaha, 
Premerlani,  Eddy,  &  Lorensen,  1991)  and  is  often  introduced  as  exten¬ 
sions  to  traditional  techniques  such  as  data  flow  diagrams.  The  focus  of 
an  object-oriented  approach  in  systems  analysis  is  typically  on  the  roles 
and  responsibilities  of  objects.  An  object  is  a  concept,  abstraction,  or 
thing  with  crisp  boundaries  and  meaning  for  the  problem  at  hand.  Ob¬ 
jects  serve  two  purposes: 

•  to  promote  understanding  of  the  real  world;  and 

•  to  provide  a  practical  basis  for  computer  implementation,  i.e.,  be¬ 
havior  is  allocated  to  an  object. 

An  overview  of  object-oriented  approaches  can  be  found  in  Monarch i 
and  Puhr  (1992).  The  following  discussion  is  based  on  Bra:k  and 
Haugen  (1993)  and  Madsen,  M0ller-Pedersen,  and  Nygaard  (1993).  Tra¬ 
ditionally,  a  number  of  techniques  are  utilized  to  manage  complexity: 

•  abstraction  (consider  the  whole  system,  but  ignore  aspects  and  re¬ 
move  implementation  details); 

•  projection  (the  system  is  perceived  from  different  angles,  e.g.,  data 
and  control  flow  views); 

•  aggregation  and  partitioning  (e.g.,  functional  or  structural  hierar¬ 
chy). 

Another  powerful  technique  introduced  in  the  object-oriented  approach 
is  generalization/specialization.  This  kind  of  complexity  management  is 
based  on  a  description  and  understanding  of  individuals  in  terms  of  simi¬ 
larity  by  extracting  general  patterns  of  properties  (types).  Components 
of  a  system  will  be  instances  of  these  types.  Instances  and  types  arc 
often  referred  to  as  objects  and  classes  in  object-oriented  terminology. 
Types  are  made  in  two  ways: 

•  by  composition,  i.e.,  aggregation  of  components  that  also  may  be 
instances  of  other  types; 

•  by  inheritance  and  specialization,  i.e.,  a  new  type  is  defined  by 
inheriting,  specializing,  and/or  redefining  the  properties  of  an  exist¬ 
ing  type. 
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Objects  contain  data  items  (called  attributes),  including  state,  iuxi 
action  sequences  (called  methods  in  object-oriented  teriiiinology)  that 
prcKess  data  items  and  received  inputs.  The  use  oF  methcxls  provides  a 
we  11 -defined  interFaee  that  hides  the  internal  structure  of  data  items  lUxl 
action  sequences  From  the  environment  (eneapsulates  the  object).  Mctlv 
(xls  rcpre.sent  an  object-oriented  implementation  of  Functions  in  daLi 
How  diagrams.  It  is  important  to  realize  that  objects  can  execute  action 
sequences  without  c\[crn'd\  stimulus.  For  example,  actions  can  be  exe¬ 
cuted  periodically.  Action  sequences  can  be  executed  in  coordination 
with  other  objects  (using  their  methods),  alternately  (interleaved)  with 
other  objects  (only  one  object  active  at  a  time),  or  concurrently  with 
other  objects  (more  than  one  object  active  at  a  time).  The  need  For  these 
types  oF  action  sequences  can  be  illustrated  by  considering  the  iiKxlcl- 
ling  oF  a  travel  agent.  Tbc  agent  alternates  between  various  sequential 
activities  such  as  invoicing  or  making  rc.scrvations,  and  tbc  alternation 
is  typically  triggered  by  telephone  interrupts.  Tbc  agent  can  also  per- 
Form  tour  planning  together  with  a  customer  in  tbc  oFHcc,  i.c.,  concur¬ 
rently  with  tbc  customer. 

An  objcct-oricnlcd  approach  to  system  development  typically  concen¬ 
trates  on  the  development  oF  an  object  model,  that  is,  the  creation  oF 
types  (classes).  The  object  nKxlcl  contains  a  description  oF  types  with 
their  attributes  and  nieth(xls.  Tbc  objects  arc  linked  by  aggregation, 
inheritance,  or  other  kinds  oF  relations.  The  control  How  is  typically 
then  described  by  a  dynamic  model  ba.scd  on  finite-state  machine  For¬ 
malism  with  various  types  oF  extensions.  Finally,  the  inFonnatron 
processing  itsclF  is  described  in  what  often  is  called  tbc  functional 
model.  The  object  modelling  technique  (GMT)  is  an  example  oF  a  tech¬ 
nique  using  these  three  modelling  projections  (Rumbaugb  ct  al.,  1991 ). 

Another  object-oriented  modelling  mctbtxl  is  SDL-92  (.Ypccillcation 
and  (^/cscription  /anguage),  which  is  a  standard  language  For  specifying 
and  describing  real-time  systems  used  within  the  telecommunications 
community,  in  SDL,  a  system  and  its  environment  arc  conceived  of  as 
a  structure  ol  /;/wA:.v  connected  by  channels.  Bkxrks  can  be  deconipo.scd, 
and  their  behavior  is  described  in  processes.  Each  process  is  nicxlellcd 
by  an  extended  llnile-statc  machine  (EFSM),  and  communication  be¬ 
tween  prcK'csscs  is  possible  only  by  signals  that  are  pnxluccd  and  con¬ 
sumed  by  the  EFSMs.  A  block  type  may  be  reused  when  a  new  bliK'k 
is  dcFincd.  The  new  block  inherits  data,  EFSM,  and  actions,  which  may 
then  be  (partly)  redefined  and/or  extended.  The  ability  to  inherit  ;ind 
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modify  behavior  in  this  way  is  a  powerful  feature.  Processes  can  be 
regarded  as  objects.  In  SDL,  function  allocation  is  performed  as  part  of 
what  is  called  implementation  design.  The  result  of  the  implementation 
design  is  a  description  of  the  system  structure  and  its  associated  bchav* 
ior.  The  function  allocation  is  described  by  the  relationship  between  the 
behavior  description  and  the  implementation  description.  SDL  models 
can  be  executed  and  their  implementation  in  software  (or  hardware)  may 
be  partly  automated. 

FUNCTION  ALLOCATION  TECHNIQUES 
IN  HUMAN  FACTORS  ENGINEERING 

Overviews  of  function  allocation  techniques  used  within  human  fac¬ 
tors  engineering  can  be  found  in  Meister  (1985),  Rouse  (1991),  and 
Beevis  (1992).  The  following  summarizes  an  iterative  approach  to  allo¬ 
cation  advocated  by  Rouse  (1991),  which  consists  of  three  passes 
through  the  allocation,  design,  and  evaluation  sequence. 

Comparative  allocation  approaches  arc  first  used  in  the  initial  design 
phase.  Functions  allocated  to  humans  are  then  converted  to  tasks  by 
designing  displays,  input  devices,  and  operating  procedures.  Human 
performance  and  workload  arc  predicted  with  emphasis  on  single-task 
performanee/workload  at  different  points  in  time.  The  design  integra¬ 
tion  phase  focuses  on  relationships  between  multiple  tasks  at  similar 
points  in  lime.  Complementary  tasks  could  point  to  more  integrated 
displays,  input  devices,  and/or  procedures  to  improve  performance  and 
reduce  workload,  while  conflicting  tasks  could  indicate  the  need  to  redes¬ 
ign  displays,  input  devices,  and/or  procedures.  In  the  final  design  phase, 
earlier  decisions  arc  reviewed  and  possible  use  of  dynamic  allocation  is 
investigated.  Use  of  prototypes  or  human-in-the-loop  simulators  is  con¬ 
sidered  necessary  in  order  to  evaluate  the  final  allocation. 

FUNCTION  ALLOCATION  WITHIN 
SYSTEM/SOFTWARE  ENGINEERING 

The  ierm  function  analysis  is  well  established  within  system/so  ft  ware 
engineering,  in  contrast  with/M//c7/V;^/  allocation,  which  often  is  treated 
as  part  of  “implementation  design"  and/or  software  design.  (A  database 
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search  resulted  in  Forty-four  matches  For  function  allocation  alone,  hut 
none  when  the  tenn  was  coinhincd  with  system  or  software  engineer¬ 
ing!)  Nevertheless,  function  allocation  is  implicit  in  distributed  system 
design,  hard  ware/ soft  ware  codesign,  general  and  real-time  software  de¬ 
sign,  and  distributed  artificial  intclligcnee  (AI)  system  design.  Since 
systcni/softwarc  engineering  puts  more  emphasis  on  the  evaluation  of 
the  design  than  on  techniques  for  function  allocation  itself,  techniques 
for  computer  systems  pcrfomiance  analysis  arc  also  relevant. 

DISTRIBUTED  SYSTEM  DESIGN 

Today  many  functions  arc  allocated  to  software  to  he  run  on  a  distrib¬ 
uted  computer  system  comprising  a  network  of  general-purpose  com¬ 
puters.  The  allocation  is  often  dynamic.  Two  or  more  computing  re¬ 
sources  arc  interconnected  if  they  can  communicate,  that  is,  exchange 
messages.  The  client-server  model  is  the  most  pervasive  for  intcrcon- 
ncctivity  (Nicol,  Wilkes,  &  Manola,  1993).  This  nicxlcl  organizes  a 
distributed  system  as  a  number  of  distributed  server  processes  that  olTcr 
various  services  to  client  processes  across  the  network.  Many  experts 
now  agree  that  modelling  of  a  distributed  system  as  a  distributed  collec¬ 
tion  of  interacting  objects  is  appropriate.  Objects  arc  clients  and  servers 
within  the  system  according  to  the  roles  allocated  to  them. 

HARDWARE/SOFTWARE  CODESIGN 

A  prominent  allcKation  problem  facing  system/software  engineering 
is,  of  course,  whether  a  function  should  be  implemented  in  hardware 
(including  firmware)  or  software.  For  most  functions,  the  decision  is 
clcarcut.  However,  functions  (or  operations)  that  can  be  implemented  in 
hardware  or  software  or  both  arc  called  hard  warc/so  ft  ware  codesign  op¬ 
erations  Dunlop,  &  Wolf,  1994).  Thc.se  types  of  functions  are 

generally  primitive,  specialized,  and  have  strict  ixirfomiance  require¬ 
ments.  EITcctivc  partitioning  (allegation)  of  codesign  operations  into 
hiudwarc  or  software  depends  on  many  factors,  including  |Xjrformance, 
cost,  maintainahility,  llcxihility,  and  size.  The  resulting  trade-off  analy¬ 
sis  closely  parallels  the  comparative  or  economical  allocation  tech¬ 
niques  in  human  factors  engineering  (Rouse,  1991). 
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DISTRIBUTED  AI  SYSTEM  DESIGN 

Multiagent  problem  solving,  a  subficld  of  distributed  AI,  is  concerned 
with  coordination,  task  decomposition,  task  allocation,  and  intcrac- 
tion/communication  among  “intelligent"  agents.  An  intelligent  agent 
may  he  defined  as  an  entity  capable  of  performing  at  least  one  of  the 
following:  sensing,  decision  making,  or  acting.  Agents  may  need  to 
share  knowledge,  goals,  and  plans  to  achieve  a  single  global  objective 
or  separate  individual  objectives  that  interact.  Agents  often  need  to  rea¬ 
son  about  the  eoordination  proeess  and  the  intentions  or  beliefs  of  other 
agents.  An  object-oriented  architecture  is  often  used  in  muliiagent  sys¬ 
tems.  Objeets,  representing  agents,  eommunicate  hy  asynchronous 
message  passing,  whieh  in  turn  ehanges  the  internal  slate  of  the  ob¬ 
jects. 

Multiagcnt  planning  tackles  the  problems  of  task  decomposition  and 
task  allocation  (i.e.,  finding  agents  that  can  execute  the  tasks).  Agents 
must  be  eapable  of  performing  a  task,  have  the  neeessary  resourees 
(e.g.,  time)  and  possess  the  required  knowledge.  Note  that  task  alloca¬ 
tion  is  itself  a  task  and  that  tasks  are  alloeated  to  agents  in  run  time.  A 
development  framework  for  agent-oriented  applications,  CADDIE,  has 
been  developed,  as  reported  by  Farhoodi  (1993).  There  are  few  examples 
of  large-scale  operational  multiagcnt  systems,  however,  and  the  tech¬ 
nology  must  be  considered  immature. 


SOFTWARE  DESIGN 


The  main  allocation  problems  in  syslcm/softwarc  engineering  arc  the 
allocation  of  behavior  to  software  components  and  the  allocation  of 
software  components  to  various  computers.  The  basic  software  compo¬ 
nents  of  traditional  software  engineering  are  processes  (programs, 
tasks)  with  independent  behavior  that  is  built  from  modules  (functions, 
subroutines,  procedures).  The  basic  components  in  object-oriented  sys- 
tcm/softwarc  engineering  arc  objects  and  methods.  An  object  might 
implement  a  process. 

Various  general  guidelines  to  implementation  design  in  software  en¬ 
gineering  have  been  proposed.  The  following  are  examples  from  Brack 
and  Haugen  (1993): 
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•  Analyze  requireinents  lor  physical  distribution  ol  interlaces  iuxl 
services.  Minimize  the  bandwidth  needed  over  channels  covering 
physieal  distances. 

•  Allocate  processes  toeomputers  in  such  a  way  that  the  mean  peak 
load  on  a  single  computer  dex^s  not  exceed  about  30  percent  ol  its 
total  capacity. 

•  Ensure  that  response-time  requirements  are  satislled  lor  time-critical 
sections  by  use  of  priority  and  isolation. 

•  Add  redundant  units  and  restruetu re  system  until  reliability  require¬ 
ments  are  satisfied. 

In  order  to  cope  with  uncertain  and  inereasing  workload  during  the  life 
cycle  of  a  product,  it  is  common  to  require  a  certain  spare  prcK'essing 
and  memory  eapaeity.  The  frequent  use  of  such  crude  guidelines  is  an 
indieation  of  the  diflleulties  involved  in  predicting  the  pcrfomiance  by 
analytical  means.  Several  guidelines  concerning  allocation  of  behavior 
to  modules  have  also  been  proposed.  The  best  known  arc  (Yourdon, 
1989): 

•  Cohesion:  Measure  of  how  well  a  particular  module's  contents,  its 
code,  and  local  data  structures  group  together.  Cohesion  (measure 
of  locality)  should  be  maximized.  Modules  should  perform  only 
one  or  a  small  set  of  operations  that  arc  grouped  for  some  logical 
(not  arbitrary)  reason. 

•  Coupling:  Degree  of  interconnection  between  modules.  Coupling 
should  be  minimized.  When  triggered,  the  module's  operation 
should  not  depend  on  values  in  global  data  .structures  or  inside  other 
modules. 

Similar  guidelines  have  also  been  extended  to  object-oriented  software 
engineering  (Coad  &  Yourdon,  1991).  The  most  important  motivation 
behind  these  guidelines  is  not  increased  processing  |xrfonnanee,  but 
reduction  of  programming  errors  and  improved  maintainability  (r.e., 
reduction  of  life-cycle  cost). 

REAL-TIME  SOITWARIi  DESIGN 

The  need  for  information  processing  in  a  real-time  system  varies  in  a 
more  or  less  stochastic  manner.  Because  system  resources  (such  as 
processing  capacity  and  memory)  are  finite,  the  allocation  of  these  le- 
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sources  to  the  processes  performing  the  information  processing  must  be 
managed  in  order  to  fulfil  deadlines.  This  allocation  is  referred  to  as 
scheduling  and  is  an  important  part  of  the  operating-system  software. 
Systems  with  absolute  timing  requirements  arc  called  hard  real-time 
systems.  There  are  two  distinct  approaches  to  scheduling  in  hard  real¬ 
time  systems:  run-time  scheduling  (on-line  scheduling,  dynamic  sched¬ 
uling)  and  pre-run-time  scheduling.  The  first  requires  that  the  schedule 
be  calculated  at  run  time  and  is  very  common  in  real-time  systems. 
Advantages  of  this  approach  are  flexibility  and  adaptability  to  changes 
in  the  environment.  Disadvantages  can  be  complexity  and  high  run-time 
cost.  In  Xu  and  Parnas  (1993),  it  is  argued  that,  given  certain  reasonable 
assumptions,  this  type  of  scheduling  cannot  guarantee  that  all  timing 
constraints  will  be  satisfied.  A  mixed  strategy  including  precalculated 
schedules  (i.e.,  fixed  allocation)  in  addition  to  run-time  scheduling  is 
necessary  in  order  to  fulfil  absolute  timing  requirements. 

EVALUATION 

Performance  analysis  of  computer  systems  (Jain,  1991)  has  several 
objectives: 

•  Determine  the  number  and  size  of  components  (capacity  planning). 

•  Evaluate  design  alternatives. 

•  Compare  two  or  more  existing  systems. 

•  Determine  optimal  parameter  values  (system  tuning). 

•  Identify  performance  bottlenecks. 

•  Characterize  system  workload. 

There  are  three  techniques  for  performance  evaluation:  analytical  mod¬ 
elling,  simulation  and  measurement.  The  latter  requires  the  existence  of 
a  prototype,  while  the  first  two  arc  analytical  methods.  The  criteria  for 
selecting  an  evaluation  technique — for  example,  time,  cost,  and  valid¬ 
ity — parallel  those  used  in  human  factors  engineering  in  studies  involv¬ 
ing  operators.  The  main  advantage  of  simulation  is  that  a  sufficiently 
accurate  evaluation  might  be  achieved  with  limited  time  and  cost.  Col¬ 
lecting  measurements  from  a  complex  distributed  computer  system  is 
dilficult  due  to  lack  of  control  of  environmental  parameters  and  might 
be  compared  with  a  human-in-the-loop  simulator  evaluation. 

The  increasing  use  of  simulations  at  various  levels,  in  order  to  select 
among  alternatives,  validate  design  solutions  (are  we  building  the 
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right  system?)  and  verify  solutions  (are  we  building  the  system  cor- 
rectly?)  is  a  major  trend  in  system/software  engineering.  The  trend  con¬ 
cerning  trade-off  analysis  is  discussed  in  the  RSG.14  report  (Beevis, 
1992). 


DISCUSSION 

Function  allocation  in  itself  is  not  a  big  issue  in  system/software 
engineering,  and  this  seems  to  parallel  the  state  of  practice  concerning 
function  allocation  within  human  factors  engineering  as  reported  by 
RSG.14  (Beevis,  1992).  The  allocation  of  functions  to  human  and  ma¬ 
chine  seems  to  depend  on  both  a  formal  analysis  and  prototyping.  The 
general  agreement  is  that  the  success  of  allocation  decisions  concerning 
operators  depends  heavily  on  the  implementation  and  that  a  prototype 
or,  rather,  an  operational  system  is  required  to  determine  its  success. 

The  dichotomy  between  human  and  machine  in  function  allocation 
seems  somewhat  artificial,  since  functions  usually  are  shared  in  some 
way  or  another.  The  main  assumption  underlying  so-called  human- 
centered  system  design  is  that  people  are  responsible  for  system  objec¬ 
tives  (at  some  operational  level).  The  implication  with  regard  to  design 
objectives  is  therefore  to  support  humans  in  achieving  the  operational 
objectives  for  which  they  are  responsible  (Rouse,  1991).  Even  though  a 
function  is  allocated  to  the  machine  (automation),  the  operator  will 
usually  have  a  supervisory  control  role,  with  the  possibility  and  the 
responsibility  to  intervene  if  necessary. 

The  allocation  is  often  regarded  as  a  mapping  from  the  lowest-level 
functions  to  a  set  of  system  components.  However,  consider  a  function 
allocated  to  the  operator.  The  operator  will  need  a  description  of  what  to 
do  (task  analysis)  and  how  (human-machine  interface,  procedures).  But 
the  operator  should  also  know  why,  and  this  makes  it  necessary  to  con¬ 
sider  functions  (behavior,  really)  at  one  or  more  higher  levels  of  abstrac¬ 
tion.  An  operator  performing  a  job  consisting  of  a  number  of  tasks  and 
responsibilities  needs  a  model  of  the  system  at  various  levels  of  abstrac¬ 
tion.  This  type  of  knowledge  is  denoted  as  the  operator's  internal 
model.  The  need  for  behavioral  and  structural  information  at  various 
levels  is  discussed  by  Rasmussen  (1986)  in  what  he  terms  the  abstrac¬ 
tion  hierarchy.  Likewise,  the  machine  may  need  a  model  of  the  opera¬ 
tor's  behavior  in  order  to  provide  adaptive  aiding  and  an  intelligent  inter¬ 
face. 


116 


Improving  Function  Allocation 


CONSEQUENCES  OF  SYSTEM/SOFTWARE  ENGINEERING 
PRACTICES  FOR  FUNCTION  ALLOCATION 

Development  of  formal  behavior  models  and  their  subsequent  analysis 
is  an  important  trend  in  system/software  engineering.  However,  the 
human  system  component  and  the  human’s  behavior  are  usually  mod¬ 
elled  only  superficially.  There  is  still  a  tendency  within  systems  engi¬ 
neering  to  draw  the  system  boundary  too  close  to  the  machine  and  away 
from  the  human.  The  implications  of  the  human-machine  interface  for 
the  total  operator  job,  or  vice  versa,  are  thus  not  analyzed  sufficiently. 

The  attitude  toward  function  allocation  seems  to  be  rather  pragmatic 
in  current  system/software  engineering  practice,  System/sofiware  engi¬ 
neers  generally  exploit  technology  as  much  as  possible  to  increase  the 
automation  level,  build  a  repertoire  of  decision  aids,  and  make  better  and 
more  intelligent  human-machine  interfaces.  Partitioning  of  functions 
into  more  or  less  mutually  exclusive  human  and  machine  sets  is  not 
really  addressed.  This  coincides  with  modem  human  factors  engineering 
views  that  such  a  partitioning  does  not  take  full  advantage  of  overlap  in 
intelligent  capabilities  between  human  and  machine. 

The  impact  of  decision  aids  on  system  performance  is  rather  difficult 
to  analyze.  Few  software/system  engineers  consider  the  potential  cost 
associated  with  the  introduction  of  decision  aids,  for  example,  that  op¬ 
erator  workload  and  system  performance  (human  and  machine)  will  be  a 
function  of  the  reliance  on  the  aid. 

It  is  generally  agreed  that  object-oriented  development  is  bound  to 
have  a  major  influence  on  the  manner  in  which  systems  are  built  (Loy, 
1 990).  Differences  in  terminology  and  modelling  practices  among  sys¬ 
tem/software  engineers  and  human  factors  engineers  might  therefore 
increase,  and  in  turn  affect  the  function  allocation  process. 

CONTRIBUTION  OF  SYSTEMS/SOFTWARE  ENGINEERING 
TO  FUNCTION  ANALYSIS 

The  most  promising  developments  with  regard  to  formal  behavior¬ 
modelling  languages  have  come  from  the  system/software  engineering 
community.  This  is  likely  to  be  true  in  the  future  as  well.  A  formal 
behavior  model  is  an  important  input  to  function  allocation.  Further, 
allocation  (and  its  basis)  should  also  be  described  formally.  This  would 
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simplify  analysis  of  the  impact  of  changes  during  a  system’s  lifetime 
and  reuse  of  existing  designs  in  new  projects. 

Whether  human  factors  engineering  can  benefit  from  object-oriented 
system  modelling  techniques  is  still  an  open  question.  Proponents  of  an 
object-oriented  approach  to  system  development  argue  that  the  model¬ 
ling  concepts  used  in  this  approach  more  closely  resemble  the  way  hu¬ 
mans  organize  knowledge  and  information;  that  is,  object-oriented  mod¬ 
elling  concepts  fit  the  internal  model  more  closely.  Modelling  an 
operator  actually  means  modelling  the  operator’s  internal  model,  so  it 
could  be  hypothesized  that  object-oriented  modelling  concepts  should  be 
more  suited  for  operator  modelling. 

Modern  modelling  languages  in  system/software  engineering  could  be 
used  to  describe  normative,  rule-based  operator  behavior  and  the  infor¬ 
mation  needs  of  knowledge-based  behavior.  Note  that  we  are  talking 
about  the  capabilities  of  the  modelling  language.  Identifying  such  op¬ 
erator  behavior,  however,  is  often  difficult.  In  circumstances  where  the 
operator  can  be  modelled  as  a  computer  system  (of  arbitrary  complexity, 
if  needed)  and  the  crew  as  a  distributed  system,  system/software  engi¬ 
neering  could  possibly  contribute  with  expertise. 

Human  engineering  might  benefit  by  modelling  operators  in  terms  of 
various  behavior-modelling  constructs  in  system/software  engineering, 
such  as  alternation,  concurrency,  and  inheritance.  In  some  cases,  behav¬ 
ior  might  be  easier  to  understand  if  alternation  or  concurrency  is  used. 
For  instance,  alternation  can  simplify  the  description  of  interrupt  han¬ 
dling. 

A  formal  behavior  model  can  be  simulated  directly  and  might  itself 
include  the  details  required  to  yield  useful  performance  data  comparable 
to  a  SAINT  (Systems  Analysis  by  Integrated  Networks  of  Tasks)  simu¬ 
lation.  A  more  realistic  scheme  is  automatic  translation  of  a  behavior 
model  to  a  discrete-event  simulation  program  to  which  more  details  can 
be  added.  This  would  enforce  a  certain  consistency  with  the  behavior 
model.  Likewise,  partly  automatic  generation  of  prototypes,  necessary 
in  order  to  evaluate  function  allocation,  might  be  supported. 

Traditional  human  factors  engineering  function  allocation  techniques 
based  on  comparison  or  cost  will  not  necessarily  result  in  a  set  of  func¬ 
tions  that  are  coherent  and  satisfactory  to  the  operator.  The  guideline  of 
assuring  maximum  cohesion,  however,  is  to  some  degree  consistent 
with  the  definition  of  a  meaningful  operator  job.  The  minimal-coupling 
guideline,  on  the  other  hand,  advocates  a  design  that  would  isolate  the 
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operator  from  the  rest  of  the  system  and  thus  complicate  updating  of  the 
operator’s  internal  system  model.  The  need  to  keep  the  operator  in  the 
loop  requires  a  design  that  contradicts  the  minimal-coupling  guideline. 
Allocation  of  functions  for  effective  and  cognitive  support  is  suggested 
by  Price  (1985)  as  one  of  four  allocation  rules. 

CONCLUSIONS 

We  see  an  increased  interest  in  using  object-oriented  techniques  in 
system  and  functional  analysis.  This  will  inevitably  affect  human  engi¬ 
neering.  For  example,  will  function  allocation  and  task  analysis  benefit 
from  system  functions  modelled  with  object-oriented  concepts?  Will 
object-oriented  concepts  make  it  easier  or  more  difficult  to  construct 
models  of  the  human-machine  system  appropriate  for  typical  human 
factors  engineering  activities?  The  claim  that  object-oriented  modelling 
techniques  map  more  closely  to  internal  model  constructs  should  be 
researched  by  human  engineering.  If  this  is  valid,  object-oriented  model¬ 
ling  techniques  could  possibly  have  something  to  offer  cognitive  task 
analysis  as  well. 

As  we  have  seen,  system/software  engineering  puts  little  emphasis  on 
developing  techniques  and  guidelines  for  function  allocation.  The  rea¬ 
son,  we  believe,  is  that  allocation  decisions  depend  heavily  on  the  ap¬ 
plication  domain,  the  capability  of  the  technology,  and  the  constraints 
under  which  a  system  is  developed.  Techniques  and  guidelines  applica¬ 
ble  across  a  broad  range  of  systems  must  necessarily  be  so  general  that 
they  are  of  little  value.  Much  more  emphasis  is  put  on  techniques  to 
evaluate  and  predict  how  a  certain  allocation  of  functions  fulfils  re¬ 
quirements.  The  main  analytical  techniques  for  these  tasks  are  model¬ 
ling  and  simulation.  For  human  factors  engineering  to  be  able  to  adopt 
these  analytical  techniques  for  evaluation  of  function  allocation  deci¬ 
sions  and  design,  models  of  cognitive  operator  tasks  applicable  for  sys¬ 
tem  development  are  much  needed. 

As  human-machine  systems  steadily  become  more  software  intensive, 
it  is  important  to  see  how  the  complete  human-machine  system,  in¬ 
cluding  the  users,  can  be  modelled  and  analyzed  within  the  frameworks 
used  by  system/software  engineering.  A  more  comprehensive  modelling 
of  the  human  part  of  the  system  requires  the  expertise  and  involvement 
of  human  engineering.  An  integrated  modelling  and  analysis,  however. 
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would  require,  to  a  large  extent,  that  human  factors  engineering  use  the 
same  modelling  languages  as  system/software  engineering. 
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FUNCTION  ALLOCATION 
IN  INFORMATION  SYSTEMS 

G.  U.  Campbell  and  P.  J.  M.  D.  Essens 


Function  allocation  is  generally  characterized  os  the  process 
that  assigns  broadly  defined  activities  to  humans  and  ma¬ 
chines  in  a  system.  Information  software  systems,  as  exempli¬ 
fied  in  command  and  control  systems,  require  a  different 
model  of  function  allocation  than  do  traditional  human- 
machine  systems.  A  two-stage  process  of  function  allocation 
was  developed  that  adds  support-based  allocation  to  tradi¬ 
tional  human-machine  allocation.  In  stage  1,  focus  is  on  hu¬ 
man-computer  strengths  and  weaknesses,  hut  absolute  and  fi¬ 
nal  allocations  are  not  the  goal.  Rather,  the  results  of  stage  f 
are  used  to  address  the  requirement  for  the  computer  to  sup¬ 
port  the  human,  a  process  that  occurs  iteratively  with  stage  2. 
The  model  was  applied  in  the  development  of  a  Canadian 
Forces  Artillery  Regimental  Data  System. 


INTRODUCTION 

It  has  been  noted  by  several  authors  (e.g.,  Meister,  1991)  that  the  deci¬ 
sions  concerning  what  to  automate  in  so  ft  ware- based  systems  differ 
from  the  deeisions  made  in  more  traditional  human-machine  systems. 
Traditionally^  the  allocations  were  treated  as  dichotomous  decisions.  In 
human-machine  systems,  if  a  function  required  lifting  heavy  weights  or 
performing  rapid  calculations,  then  allocation  could  be  assigned  unam¬ 
biguously  to  a  machine.  If  complex  pattern  recognition  was  required, 
then  the  function  was  assigned  just  as  unambiguously  to  the  human 
operator.  In  software- based  systems,  automation  relates  less  to  labor  and 
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far  more  to  human  information-processing  and  cognitive  models.  Speci¬ 
fication  of  functions  and  tasks  shifts  toward  a  more  cognitive  focus. 

Given  this  shift  in  focus,  traditional  function  allocation  is  not  appro¬ 
priate  in  the  development  of  software  systems.  Rather  than  discarding 
function  allocation  altogether,  however,  we  can  retain  and  enhance  its 
value  by  adding  new  concepts.  In  the  new  conceptualization,  the  possi¬ 
ble  roles  that  the  computer  and  the  human  can  play  in  the  developing 
system  are  of  primary  concern.  Guidelines  for  defining  such  concepts 
should  specify  that  the  capabilities  of  humans  and  machines  should 
augment  and  enhance  each  other.  Function  allocation  should  be  done  on 
the  basis  of  combined  human-computer  strengths  and  weaknesses,  with 
the  overriding  goal  being  to  optimize  the  performance  of  work.  Three 
general  allocation  categories  can  be  distinguished:  operator  primarily, 
human-machine  mix,  and  machine  primarily  (Meister,  1985). 


HUMAN-COMPUTER-PROCESS  RELATIONSHIPS 

Recently,  concepts  such  as  support  systems  and  joint  systems  have 
become  popular  (Woods  &  Roth,  1988).  Together  with  the  concept  of 
supervisory  systems  (Sheridan,  1988),  these  concepts  address  the  rela¬ 
tionship  between  the  human  and  the  computer  in  dealing  with  the  proc¬ 
esses  they  must  control  or  manipulate.  Four  human-computer-process 
interactions  can  be  distinguished  (see  Figure  7.1): 

Split  model.  The  split  model  represents  the  more  traditional  allocation 
approach  in  that  the  interaction  with  the  process  is  statically  divided 
between  a  human  and  a  machine  or  computer. 

Mediation  model.  In  this  model,  the  computer  is  the  mediator  be¬ 
tween  the  human  and  the  process.  The  mediation  model  is  typical  of 
supervisory  control  defined  in  the  strict  sense  (Sheridan,  1987).  Essen¬ 
tially,  the  computer  acts  on  input  from  the  process.  In  this  conceptuali¬ 
zation,  the  relationship  between  the  computer  and  the  human  can  have 
several  definitions.  For  example,  this  model  includes  the  case  where  the 
computer  selects  an  action  and  informs  the  human,  who  can  then  opt  to 
stop  the  process.  Similarly,  the  computer  may  complete  the  entire  job 
and  inform  the  human  of  the  results,  if  requested  or  required. 

Support  model.  In  the  support  model,  the  human  interacts  with  the 
process  and  the  computer  supports  the  human  whenever  the  human 
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Figure  7.1.  Roles  of  human  and  computer  in  handling  the  processes 
they  control. 
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requests  support.  This  tool-like  configuration  is  characteristic  of  many 
decision-making  situations.  For  example,  an  intelligence  system  that 
supports  the  commander  in  identifying  enemy  organizations  by  drawing 
from  a  database  of  past  activities  would  be  representative  of  this  model. 

Complementary  model.  In  the  complementary  model,  there  is  a 
shared  role  in  managing  the  process.  Both  human  and  computer  act  on 
the  process  in  a  dynamie  role  allocation.  The  allocation  is  based  on 
operational  eonditions,  workloads,  and  priorities. 

A  fifth  interaction  model  is  also  conceivable.  In  this  final  eonceptu- 
alization,  the  human  becomes  the  mediator  and  the  computer  dictates 
what  should  be  done.  This  model  is  currently  employed  by  some  sci¬ 
ence-fiction  writers. 

The  central  issue  is  that  conceptually  different  roles  for  computers  and 
for  humans  are  possible  within  a  system.  The  concept  of  respective 
roles  for  humans  and  computers  suggests  specific  allocation  questions 
to  be  considered  in  the  design  of  the  system.  Information  systems  that 
arc  emerging  in  command  and  control  typically  serve  functions  such  as 
handling  and  storing  large  volumes  of  data  and  facilitating  communica¬ 
tions.  At  the  same  time,  they  provide  opportunities  for  the  introduction 
of  support  concepts  in  the  eommand  and  eontrol  process.  In  these  sys¬ 
tems,  one  role  of  the  computer  is  to  support  the  human  operator  as 
described  in  the  support  model,  above. 

Software  engineers  are  paying  increased  attention  to  and  are  more 
aware  of  the  human  operator  as  an  integral  part  of  system  design.  Atten¬ 
tion  to  the  operator  as  part  of  the  system  is  a  fundamental  shift  from 
the  traditional  engineering  approach  to  integrated  system  development. 
Without  an  appropriate  process,  however,  software  system  designers 
tend  to  focus  on  developing  the  elements  of  the  system  per  se  and  pay 
scant  attention  to  the  tasks  or  cognitive  models  of  the  operators 
(Beevis,  1992).  The  two-stage  function  allocation  process  presented  here 
helps  designers  focus  on  and  address  the  role  of  the  operator  and  the 
computer  in  the  system  in  the  light  of  the  system  goals  that  must  be 
achieved.  It  encourages  the  designers  to  think  in  terms  of  supporting 
operators  in  their  performance. 

A  TWO-STAGE  FUNCTION  ALLOCATION  PROCESS 

Although  the  multipurpose  use  of  the  computer  in  software  systems 
allows  roles  to  be  combined  in  one  machine,  allocation  decisions 


Figure  7.2.  Two-stage  model  of  function  allocation  in  information  systems. 


126 


Improving  Function  Allocation 


should  reflect  and  optimize  the  possible  different  roles  of  the  human  and 
the  computer.  Since  one  role  of  the  computer  is  to  support  the  human, 
allocation  questions  should  address  the  capabilities  and  limitations  of 
the  human  and  the  interaction  with  the  process.  To  accommodate  this 
concept  of  function  allocation,  an  iterative  process  comprised  of  two 
stages  is  proposed  here  (see  Figure  7.2).  The  two-stage  process  can  be 
thought  of  as  a  way  to  integrate  the  split  model  and  the  support  model. 
The  first  stage  addresses  the  split  model  and  the  second  stage  addresses 
the  support  model.  The  result  approximates  a  complementary  model 
without  discussing  dynamic  allocation  but  instead  focusing  on  the  roles 
of  the  human  and  computer  and  the  integration  of  the  models. 

Preliminary  Stage  (function  analysis).  Prior  to  any  function  alloca¬ 
tion  process,  a  function  analysis  of  the  system’s  objectives  is  con¬ 
ducted.  The  result  is  a  specification  of  functions,  usually  relative  to 
each  other  against  time. 

Stage  L  Essentially,  traditional  questions  of  human  and  machine  ca¬ 
pabilities  are  asked.  Allocations  are  made  to  human,  computer,  or  a 
combination  of  the  two  based  on  a  combination  of  eighteen  criteria 
(shown  in  Table  7.1).  These  criteria  reflect  the  traditional  allocation 
dichotomy. 

Stage  2.  Allocations  from  stage  1  are  further  analyzed.  Exclusively 
computer  allocations  arc  subjected  to  computer  function  analysis  via 
systems  engineering  methods.  Exclusively  human  and  combined  hu¬ 
man/computer  allocations  are  analyzed  to  determine  what  support  can  be 
provided  to  the  human  and  what  Joint  operations  require  an  interaction 
between  the  human  and  computer.  Joint  operations  are  then  examined  to 
determine  how  the  roles  can  be  optimized. 

In  essence,  then,  we  propose  an  iterative  process  in  which  the  first 
stage  highlights  the  relative  strengths  and  weaknesses  of  humans  and 
computers.  The  second  stage  uses  the  information  from  the  first  to  fo¬ 
cus  and  direct  further  analysis.  Because  the  process  is  iterative,  the  allo¬ 
cations  may  change  as  new  data  or  opportunities  become  clear.  In  the 
following,  we  describe  how  the  first  stage  was  applied  in  an  informa¬ 
tion-system  project.  Methods  for  the  second  stage  of  the  allocation 
process,  task  analysis  and  cognitive  task  analysis,  can  be  found  in,  for 
instance,  Beevis  (1992),  and  Essens,  Fallesen,  McCann,  Cannon- 
Bowers,  and  Dorfel  (1994). 
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THE  APPLICATION  OF  FUNCTION  ALLOCATION 
IN  ARDS/ADM 

The  two-stage  process  was  developed  at  MacDonald  Dettwiler  and 
Associates  (MDA)  in  interaction  with  the  TNO  Human  Factors  Re¬ 
search  Institute  and  was  applied  to  the  systems  development  of  the  Ad¬ 
vanced  Development  Model  of  an  Artillery  Regiment  Defence  System 
(ARDS/ADM). 

Only  after  the  start  of  the  ARDS/ADM  project  did  it  become  clear 
that  focus  on  the  human  operator  would  be  necessary  for  successful 
development  of  the  system.  MDA's  project  team  recognized  the  need  to 
ensure  that  the  delivered  system  would  be  usable  and  acceptable  in  the 
field.  In  successful  user-oriented  design,  the  design  process  gives  prime 
consideration  to  ensuring  that  the  users’  tasks  are  addressed  as  part  of 
system  development,  rather  than  adhering  strictly  to  a  traditional  engi¬ 
neering  model  that  focuses  on  the  hardware  and  software  of  the  system 
itself. 

The  function  allocation  process  presented  here  was  developed  in  re¬ 
sponse  to  a  variety  of  requirements.  First,  to  be  adopted  successfully  in 
industry,  any  analytical  approach  must  be  cost-effective.  It  must  provide 
maximum  utility  at  minimum  cost.  The  ARDS/ADM  project  encom¬ 
passes  a  large  problem  area  that  embodies  a  complex  set  of  human 
tasks.  An  absolutely  exhaustive  function  and  task  analysis  was  beyond 
the  scope  of  the  project  and  was  a  risk  to  be  avoided.  A  feature  of  the 
function  allocation  process  described  here  is  that  it  discouraged  overanal¬ 
ysis  of  the  ARDS/ADM  functions;  that  is,  initial  function  allocation 
(stage  1)  began  with  reasonably  high-level  functions  specified.  In  in¬ 
stances  where  the  stage  1  process  suggested  mixed  allocation,  the  func¬ 
tion  was  decomposed  further.  The  process  was  repeated  as  necessary 
until  the  tasks  and  functions  were  defined  sufficiently.  Essentially, 
overspecification  was  reduced. 

Second,  as  is  common  in  the  industry,  few  engineers  on  the 
ARDS/ ADM  project  team  had  experience  in  structured  function  or  task 
analysis.  The  iterative  approach  fostered  an  acceptable  comfort  level 
because  the  function  allocation  process  was  perceived  as  flexible. 

Third,  because  the  absolute  judgements  required  by  traditional  func¬ 
tion  allocation  methods  are  difficult  to  make,  the  new  process  used 
paired  comparison  judgements  to  perform  allocation  assignments.  This 
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shift  in  technique  meant  that  domain  experts  (subject-matter  experts) 
could  learn  to  apply  the  process  with  minimal  training,  and  the  process 
was  completed  very  quickly  even  for  large  numbers  of  functions. 

Fourth,  the  traditional  model  (the  split  model,  in  Figure  7.1)  was 
determined  to  be  inadequate  for  ARDS/ ADM  software  development.  For 
ARDS/ADM  development,  the  appropriate  model  of  human-computer- 
process  interactions  was  one  in  which  the  computer  supports  the  human 
(the  support  model).  The  traditional  approach  did  not  take  adequate  ac¬ 
count  of  the  cognitive  models  and  information  processing  that  led  to 
particular  allocations,  nor  did  the  traditional  approach  focus  design  at¬ 
tention  on  how  to  support  the  user  in  the  tasks  allocated  to  the  humans. 
In  general,  then,  the  process  presented  here  provides  more  useful  and 
appropriate  analysis  of  the  user's  role  as  part  of  a  complete  system. 

In  addition  to  fostering  an  improved  understanding  of  the  mutually 
supportive  roles  of  the  human  and  the  computer,  the  ease  with  which 
the  process  can  be  applied  ensures  proper  and  capable  application.  Sim¬ 
plicity  is  particularly  important  because  many  contractors  do  not  have 
human  factors  specialists  on  staff.  Some  companies  assign  an  engineer¬ 
ing  team  member  the  responsibility  for  the  human  factors  engineering 
aspects  of  a  project.  That  party  often  does  not  have  any  training  in  hu¬ 
man-related  analysis.  Accordingly,  the  method  presented  here  was  de¬ 
signed  to  be  applied  with  little  training. 

Prior  to  applying  the  two-stage  function  allocation  process  described 
here,  the  functions  are  specified.  (In  ARDS/ADM  development,  the 
specification  was  done  by  an  MDA  human  factors  specialist  and  two 
expert  artillery  officers.)  Identified  functions  arc  organized  in  a  function 
allocation  decision  sheet  format  that  allows  easy  comparison  of  each 
function  against  a  set  of  allocation  criteria.  The  function  allocation  de¬ 
cision  sheet  is  comprised  of  a  set  of  allocation  criteria  pairs  develcped 
from  the  seminal  work  of  Fitts  (1951,  cited  in  Salvendy,  1987)  and 
Bekey  (1970)  and  is  presented  in  Table  7.1.  The  allocation  comparisons 
allow  the  domain  expert  to  allot  functions  to  humans  or  computers  (or 
both)  based  on  the  capabilities  of  each.  The  comparisons  address  c^a- 
bilitics  such  as  short-term  memory,  ready  access  to  information,  and 
inductive  versus  deductive  reasoning.  The  comparisons  describe  inherent 
capabilities  and  so  are  independent  of  the  hardware  available,  details  of 
design,  or  implementation  options. 

In  stage  1  of  the  function  allocation  process,  one  or  more  domain 
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experts  review  each  specified  function  against  each  pair  of  criteria.  (On 
the  ARDS/ADM  project,  the  primary  domain  expert  was  a  trained  artil¬ 
lery  officer.  A  second  domain  expert,  an  MDA  employee  familiar  with 
the  domain,  also  completed  part  of  the  allocation  process.)  The  alloca¬ 
tion  of  the  function  on  each  of  the  criteria  is  then  tallied.  The  resulting 
sum  is  examined  to  determine  how  many  of  the  criteria  favor  human 
strengths  and  how  many  suggest  computer  implementation.  At  the 
completion  of  stage  I,  each  function  is  allocated  to  humans,  maehines, 
or  a  combination  of  both.  The  allocations  are  examined  further  in  the 
second  stage  of  the  function  allocation  process. 

When  the  function  allocation  tally  from  stage  I  points  to  a  machine 
implementation,  the  designer  takes  into  account  the  actual  capabilities 
that  led  to  the  allocation  of  the  function  to  the  computer  in  the  first 
place.  For  example,  the  function  may  require  computation,  a  skill  at 
which  humans  are  notoriously  weak.  The  appropriate  implementation 
can  then  be  addressed  by  the  software  design  team. 

If  the  allocation  tally  from  stage  I  points  to  assignment  to  the  human 
operator,  then  further  decomposition  helps  determine  any  information 
that  can  help  support  the  person  to  px^rform  the  tasks  related  to  that 
function. 

Any  allocation  that  is  at  least  partially  assigned  to  the  human  opera¬ 
tor  is  further  examined  to  determine  if  machine  support  of  that  function 
is  appropriate.  Mixed  allocations  are  decomposed  to  determine  which 
functions  should  be  allocated  to  the  machine  and  which  tasks  to  the 
human  operator,  and  again  human  tasks  arc  examined  to  see  if  computer 
support  has  potential  benefits.  Strictly  machine  functions  arc  not  ana¬ 
lyzed  further. 

As  expected,  many  functions  in  ARDS/ADM  require  the  capabilities 
of  both  human  and  machines,  because  the  command  and  control  func¬ 
tions  involve  human  decision  making.  Decomposition  of  these  func¬ 
tions  indicated  which  parts  of  the  function  should  be  assigned  to  ma¬ 
chines  and  which  to  humans,  and  provided  initial  information  that  was 
used  to  determine  how  the  human  tasks  could  be  supported.  For  exam¬ 
ple,  the  allocation  of  the  function  “Conduct  quick  time  estimate"  under 
the  “Warning  Phase"  on  the  function  allocation  decision  sheet  (Table 
7.1)  indicates  that  repeating  strategies  and  performing  complex,  rapid 
calculations  arc  areas  for  support  in  a  mainly  human-operated  function. 
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TRAINING  AND  INSTRUCTIONS 

To  achieve  a  valid  function  allocation  analysis,  the  evaluator  must  be 
familiar  with  the  domain.  On  ARDS/ADM,  the  primary  domain  expert 
was  a  trained  artillery  officer.  A  second  domain  expert,  an  engineer  fa¬ 
miliar  with  the  domain,  also  conducted  part  of  the  function  evaluation. 
After  as  little  as  30  minutes  of  training,  each  domain  expert  was  con¬ 
versant  enough  with  the  process  to  continue  without  support. 

As  part  of  the  training  process,  the  evaluators  walked  through  a  num¬ 
ber  of  the  functions  with  a  human  factors  specialist  (the  first  author  of 
the  current  paper).  The  eighteen  comparisons  were  repeated  for  enough 
functions  to  allow  the  domain  experts  to  feel  comfortable  with  the 
process  and  their  role.  The  domain  experts  were  encouraged  to  make 
relatively  quick  decisions  and  were  assured  that  their  first  impression  is 
likely  to  be  the  most  valid. 

Not  surprisingly,  in  many  instances  the  analysis  led  to  assignments 
that  were  counterintuitive  to  the  domain  experts.  To  prevent  the  domain 
experts  from  reevaluating  the  assignment  in  order  to  make  it  match 
expectations,  the  domain  experts  were  assured  that  these  discrepancies 
were  valuable  results  of  the  process.  Comfort  with  the  process  was  also 
enhanced  by  assurance  that  the  function  allocations  were  not  absolute, 
that  the  results  of  the  analysis  would  be  used  to  further  understand  the 
entire  human/computer  system  rather  than  be  applied  as  fixed  answers. 

CONCLUSIONS 

A  systematic  allocation  process  is  vital  to  optimizing  automated  sup¬ 
port  of  any  mission.  The  method  presented  here  provides  a  generic  tool 
that  allows  the  designer  to  allocate  functions  to  people  or  machines 
based  on  systematic  consideration  of  computer/human  capabilities. 
While  function  allocation  can  be  done  on  an  ad  hoc  basis — and  often 
is — the  process  developed  here  enforces  consideration  of  each  function 
in  terms  of  a  specific  set  of  factors,  ensuring  that  all  factors  are  consid¬ 
ered  and  providing  an  objective  basis  for  the  decisions. 

In  addition,  the  process  embodies  a  user-centered  approach  that  forces 
consideration  of  the  user  as  a  part  of  the  system.  The  model  under 
which  the  approach  was  developed  assumes  that  the  interaction  with  the 
process  is  not  statically  divided  between  the  human  and  computer. 
Rather,  the  human  interacts  with  the  process.  To  optimize  that  interac- 
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tion  and  ensure  adequate  support  for  the  human,  the  results  of  an  initial 
function  allocation  process  are  further  reviewed  to  determine  where  and 
how  the  computer  can  best  support  the  person.  To  do  so,  the  designers 
must  take  into  account  human  and  computer  strengths  and  weaknesses 
and  the  cognitive  mcxiels  of  the  user. 

The  results  of  a  function  allocation  process  provide  a  systematic  basis 
for  making  judgements  and  an  objective  basis  for  design  decisions. 
Also,  the  results  point  explicitly  to  those  functions  that  need  to  be  un¬ 
derstood  in  more  detail,  while  allowing  the  remainder  to  be  addressed 
immediately. 

Certainly,  the  method  presented  here  and  applied  in  the  development 
of  ARDS/ADM  points  to  allocations  that  are  counterintuitive  both  to 
the  domain  experts  and  to  the  design  engineers.  Equally  important,  the 
method  focuses  attention  on  the  operator’s  tasks,  missions,  and  cogni¬ 
tive  models.  Finally,  the  method  is  effective,  efficient,  and  usable. 

FURTHER  DEVELOPMENT 

To  be  most  effective,  this  method  should  be  applied  early  in  the  de* 
velopment  of  a  software  system.  It  is  less  effective  to  apply  the  results 
of  a  function  analysis  in  a  project  that  has  already  begun  system  design, 
data  modelling,  or  software  development.  The  functions  should  be  de¬ 
fined  and  the  allocation  process  begun  in  the  first  phase  of  the  project. 

Unfortunately,  on  the  ARDS/ADM  project,  the  analysis  was  delayed 
until  after  the  project  had  begun  and  system  design  was  well  under  way. 
While  the  process  was  useful  and  was  beneficial  to  the  development  of 
the  project,  it  would  have  had  greater  impact  if  it  had  been  conducted 
much  earlier.  This  would  have  provided  much  better  understanding  of 
the  users'  tasks  in  the  initial  system  concepts  and  earlier  focus  by  the 
design  team  on  the  human  element  of  the  ARDS/ADM  system. 

The  process  itself  requires  some  modifications.  To  increase  comfort 
levels  of  the  domain  experts,  the  instructions  should  include  assurances 
that  allocations  that  are  counterintuitive  provide  valuable  infonnation. 
As  well,  assurance  that  the  allocations  will  be  examined  in  more  detail 
increases  the  domain  experts’  confidence  in  their  own  decisions  and  al¬ 
lows  them  to  complete  the  process  more  quickly  and  use  their  experi¬ 
ence  to  make  rapid  decisions. 

Domain  experts  rarely  have  experience  in  human  factors  analysis. 
Asking  them  to  complete  the  function  allocation  decision  sheet  requires 
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some  preparation,  although  it  is  not  arduous  or  extensive.  It  is  worth¬ 
while  to  take  a  few  minutes  to  prepare  a  detailed  explanation  of  the 
meaning  of  each  of  the  criteria.  This  guide  should  be  targeted  to  users 
with  little  or  no  knowledge  of  human  information  processing  or  percep¬ 
tion.  It  should  be  available  to  the  domain  expert  for  reference. 

We  caution  that  no  one  function  allocation  process  is  appropriate  for 
all  software  system  development.  The  process  presented  here  is  effective 
as  an  initial  step.  In  many  environments,  it  may  be  the  only  step.  Its 
use  does  not  preclude  the  application  of  other  processes.  Ideally,  the 
results  of  this  allocation  method  will  form  the  basis  for  other  processes. 
For  example,  using  the  output  of  this  function  allocation  process  as  a 
base,  prototypes  can  be  built  exploring  various  combinations  of  alloca¬ 
tions  and  support  structures  to  maximize  effectiveness. 
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TASK  AND  WORKLOAD  ANALYSIS  FOR  ARMY 
COMMAND,  CONTROL,  COMMUNICATIONS, 
AND  INTELLIGENCE  (C'l)  SYSTEMS 

B.  G.  Knapp 


The  emergence  of  highly  automated  information  processing 
systems  being  developed  by  the  US  Army  command,  control, 
communications,  and  intelligence  (Cfl)  community  raises 
certain  questions  related  to  the  design  of  crews  and  inter¬ 
faces  for  these  systems.  The  US  Army  Research  Laboratory 
(ARL)  at  Fort  Huachuca,  with  expertise  in  information  proc¬ 
essing  and  behavioral  science,  has  recently  structured  its  re¬ 
search  support  to  the  Cfl  community  to  develop  systematic 
and  quantitative  methods  for  addressing  these  questions.  This 
paper  describes  the  approach  taken  in  the  development  and 
application  of  job  and  workload  assessment  methods  for  new 
Army  C^I  systems  and  the  implications  for  function  allocation. 
Methodologically,  what  was  adopted  was  the  measurement  of 
Cfl  task  and  job  demands  associated  with  new  systems  and 
new  operating  contexts,  so  that  these  demands  could  be  com¬ 
pared  to  current  performance  baselines.  Critical  parameters 
for  comparison  are  the  demands  placed  on  soldiers  due  to 
new  job  factors  and  mission  conditions,  and  soldiers'  knowl¬ 
edge,  skills,  and  abilities.  A  series  of  six  steps  in  the  method 
for  C^l  task  and  workload  analysis  are  described  and  illus¬ 
trated  using  two  case  studies. 


INTRODUCTION 

The  US  Army  continuously  reviews  its  missions,  develops  new  tactics 
and  plans,  and  acquires  new  equipment  in  order  to  fulfil  its  modem  de- 
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fense  roles.  A  critical  issue  for  Army  decision  makers  is  ensuring  that 
soldiers,  as  currently  selected  and  trained,  are  capable  of  operating  the 
new  equipment  and  performing  effectively.  In  particular,  the  emergence 
of  highly  automated  information-processing  systems  being  developed 
by  the  Army  command,  control,  communications,  and  intelligence  (C^I) 
community  raises  certain  questions:  How  well  do  the  capabilities  of 
current  Army  personnel  match  the  demands  and  designs  of  the  high- 
technology,  supervisory  control  systems  being  developed?  Do  the  new 
systems  differ  incrementally  or  exponentially  in  workload  from  imme¬ 
diately  preceding  systems?  What  are  the  tactical  operating  procedures 
and  training  implications  of  introducing  the  new  automation  compo¬ 
nents? 

The  US  Army  Research  Laboratory  (ARL)  at  Fort  Huachuca,  with 
expertise  in  information  processing  and  behavioral  science,  has  recently 
structured  its  research  support  to  the  C^I  community  to  develop  system¬ 
atic  and  quantitative  methods  for  addressing  these  questions.  Efforts 
have  been  targeted  at  assessing  task  performance  during  C^I  system  de¬ 
sign  stages,  prior  to  final  testing,  to  ensure  that  functions  and  tasks  are 
optimally  distributed  among  soldiers  and  automated  processors,  and  that 
information-processing  workload  does  not  exceed  resource  capabilities. 
This  paper  describes  the  approach  taken  in  the  development  and  applica¬ 
tion  of  job  and  workload  assessment  methods  for  new  Army  C^I  sys¬ 
tems  and  the  implications  for  function  allocation. 

DEVELOPMENT  OF  THE  METHOD 

The  methods  being  developed  by  ARL  are  designed  to  assess  the  im¬ 
pact  of  mission,  task,  personnel,  and  environmental  variables  (e.g.,  new 
equipment,  expanding  scope  of  tactical  missions,  increased  battlefield 
tempo,  new  operating  tactics,  changing  personnel  characteristics  in  an 
all -volunteer  Army,  etc.)  on  C^I  soldier  performance  by  augmenting  or 
supplanting  conventional  task  analysis  and  workload  estimation  tech¬ 
niques.  Conventional  methods  have  been  adequate  for  the  procedure- 
oriented,  perceptual -motor  tasks  characteristic  of  aviation,  maneuver, 
and  weapon  control  systems,  but  they  are  not  sufficient  to  address  the 
process -oriented,  cognitive  tasks  central  to  C^I  systems.  It  was  clear 
that  function  allocation  for  C^I  systems  must  be  supported  by  a  more 
comprehensive  and  elaborate  task  and  workload  definition  and  analysis 
process,  allowing  collection  of  data  that  can  be  used  persuasively  in 
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deciding  among  alternative  soldier  and  machine  function  allocation  de¬ 
signs. 

Methodologically,  what  was  adopted  was  the  measurement  of  CM  task 
dnd  job  demands  associated  with  new  systems  and  new  operating  con¬ 
texts,  so  that  these  demands  could  be  compared  to  eunrent  pcrfonuance 
baselines.  Critical  parameters  for  comparison  are  the  demands  placed  on 
soldiers  due  to  new  job  factors  and  mission  conditions,  and  soldiers 
knowledge,  skills,  and  abilities. 

This  approach  departs  from  conventional  task  decomposition  and  time 
studies  that  rely  on  time  per  task  and  additive  network  models  to  detect 
work  overload.  Instead,  information-processing  tasks  are  measured  not 
so  much  in  terms  of  time  spent  but  in  terms  of  resources  used  to  prev 
duce  information  prcxlucts  (situation  report,  battle  plan,  operations  or¬ 
der,  etc.).  A  strong  case  can  be  made  that  increased  cognitive  demands, 
along  with  a  decrease  in  time  available  for  information  processing,  will 
cause  information  output  products  to  be  compromised.  Add  to  this  any 
degradations  in  environmental  and  communications  factors,  and  the  al¬ 
location  of  functions  between  humans  and  automation  becomes  critical. 

STEPS  IN  THE  METHOD 

Task  and  workload  analysis  for  CM  missions  ba.sed  on  resource  de¬ 
mands  involves  the  series  of  steps  described  below: 

•  Step  I:  State  issues  and  objectives  of  analysis  to  focus  on  methods 
needed.  Depending  on  the  questions  being  raised,  this  allows  data 
collection  to  be  targeted  to  exactly  what  is  needed.  For  example,  is 
allocation  of  soldier  functions  related  to  declining  personnel  inven¬ 
tories,  design  of  training  plans,  need  for  equipment  specifications, 
or  a  combination  of  factors? 

•  Step  2:  Derive  mission-event  flow  and  anticipated  scenario  se¬ 
quences.  Sessions  with  subject  matter-experts  must  prcKCcd  be¬ 
yond  eliciting  traditional  task  lists  to  depicting  graphical  represen¬ 
tations  of  task  and  work  Hows  triggered  by  scenario  iuid 
information  events.  This  allows  subsequent  analysis  to  account  for 
task  loops,  decision  points,  and  communication  lines  (person  and 
machine).  An  example  of  a  simple  task  flow  diagram  is  shown  in 
Figure  8. 1 . 
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Figure  8.1 


Sample  task  How  diagram. 
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•  Step  3:  Conduct  assessment  of  cognitive  functions  and  tasks 
within  the  work  flow  by  measuring  relevant  task  and  environ¬ 
mental  characteristics  (c.g.,  attributes  of  incoming  information, 
work  environment  design,  ambient  conditions,  mission  conditions, 
etc.)  and  soldier  resources  (performance  capabilities,  knowledge, 
skills,  abilities,  and  limits).  This  extends  steps  1  and  2  by 
selecting  for  measurement  the  variables  pertinent  to  the  job  within 
the  context  of  the  issues.  A  sample  listing  of  potential  Job 
variables  from  which  such  selections  could  be  made  is  shown  in 
Table  8.1. 

•  Step  4:  Identify  potential  information  inputs  and  decision-action 
outputs.  Ineoming  information  is  the  stimulus  to  action  (task  per¬ 
formance),  and  outgoing  information  products  result  from  data 
transformation  and  analysis  tasks  that  produce  operator  decisions 
and  actions.  This  step  provides  initial  insight  into  how  the  work 
could  be  distributed  among  crew  members  and  machine  processors, 
since  various  diagrams,  variable  listings,  and  preliminary  values 
fonn  a  picture  of  the  job  situation. 

•  Step  5:  Assess  workload  by  formally  measuring  task  demands, 
under  different  mission  conditions,  soldier  capabilities,  and  envi¬ 
ronmental  variables.  Depending  on  the  issue,  task  demand  is 
measured  on  one  or  a  combination  of  variables.  Measures  are  drawn 
from  existing  human  perlbrmanee  databases  or  from  data  eolleeted 
from  experts  using  available  or  custom-designed  measurement  in¬ 
struments. 

•  Step  6:  Construct  integrated  task  and  workload  models.  A 
“model”  of  the  CM  tasks  and  asscx:iated  workload  for  a  given  job 
may  be  as  simple  as  a  paper-and-pencil  tally  and  comparison  of  the 
measures  on  a  few  variables.  Or  it  may  involve  a  complex  network 
representation  of  tasks,  task  interrelationships,  and  workload  pa¬ 
rameter  values  for  the  tasks  that  requires  a  more  sophisticated, 
computer-based  analysis.  In  either  case,  workload  profiles  are  de¬ 
veloped  and  compared  to  derive  the  impacts  of  important  factors  iif- 
feeting  task  performance. 
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Table  8.1.  Example  of  job  variables  for  workload  assessment 


1.0  Operational  Environment 

Scenario  Pece  (threet  complexity  •  #  entities,  time  pressure, 
scope  of  mission)  Operetionel  Mode  (plan  or  execute) 

Tactic  Mode  (offenses  or  defense) 

2.0  System  Environment 

Autometion  Level  (manual,  Auto  1,  Auto  2,  Auto  3) 

System  I/O  Complexity  (high,  medium,  low) 

Required  Protocols  (difficult,  moderate,  easy) 

3.0  Incoming  Information  end  Detebase  Environment 

Form  (text,  voice,  fece-to-fece,  mep  grephics,  imegery) 

Source  (commander,  staff,  subordinate,  flenk  unit,  higher 
authority)  Content  (orders,  guidance,  status,  situation  report, 
system  elerts)  Rete  (frequency  of  incomings  by  type) 

4.0  Linking  Demands 

Interectlon-Autonomy  Level  (high,  moderate,  low) 

Input-Output  Chennels  (number  end  type) 

Network  Complexity  (meny  links  and  nodes,  moderete,  few) 

5.0  Cognitive  Processing  Stete 

A.  Information  Acquisition  (complex,  moderate,  nearly  automatic) 

B.  Informetion  Trensmission  (complex,  moderete,  routine) 

C.  Date  Manipulation  (complex,  moderete,  simplistic) 

D.  Wargaming  (prediction-inference,  analysis,  option  generation) 

6.0  Workspace  Attributes 

Soldier  Machine  Interface  (user-unfriendly,  mixed,  user-friendly) 
Ambient  Conditions  (extreme,  moderate,  just  right) 

7.0  Group  Integrity 

Mobility  Stete  (stationery-all  together,  stationary-distributed, 
mobile-stationary  mix,  all  mobile)  Information  Exchange  Capability 
(face-to-fece,  voice,  digital)  Cluster  Configuration  (functional  area, 
matrix,  novel) 

8.0  Personnel  Status 

Skill  Mix  (experienced,  experienced-inexperienced  mix, 
inexperienced)  Composition  (technical,  enalytical,  supervisory) 
Shift  Protocol  (all  dedicated,  trade-offs) 

Numbers  Per  Call 
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APPLICATION  OF  THE  METHOD: 

TWO  CASE  STUDIES 

ARMY  AIRCREW  REQUIREMENTS  FOR  JSTARS 
Step  ! 

Of  immediate  interest  for  certain  Army  intelligence  systems  is  the 
assessment  and  comparison  of  skill  and  ability  requirements  needed  for 
tasks  by  prospective  soldiers.  For  the  Joint  Survcillance/Targct  Acquisi¬ 
tion  Radar  System  (JSTARS)»  a  new  high-technology  intelligence  sen¬ 
sor  system  designed  to  provide  real-time  imagery  information  on  the 
tactical  battlefield^  a  question  arose  regarding  the  suitability  of  current 
personnel  for  performing  job  tasks  on  both  the  prototype  and  the  objec¬ 
tive  system.  At  issue  was  whether  imagery  operators  would  be  over¬ 
loaded  by  the  proposed  capabilities  of  the  objective  system.  The  initial 
job  was  performed  by  two  imagery  operators  using  a  limited,  prototype 
version  of  JSTARS  in  Operation  Desert  Storm  (the  199!  Gulf  War). 
The  objective  system  could  accommodate  three  operators,  if  needed. 

Step  2 

The  JSTARS  job  How  was  obtained  from  JSTARS  experts:  those 
familiar  with  functions  performed  in  predecessor  and  prototype  systems, 
and  those  designing  the  objective  JSTARS.  The  funetional  job  How  is 
shown  in  Figure  8.2.  Six  functions  were  idcntillcd:  mission  planning, 
brief,  preflight,  outbound  Hight,  on-station  mission  performance,  and 
post-mission  duties  and  debrief.  Of  greatest  interest  for  demand  assess¬ 
ment  was  the  on-slation  mission  function.  A  further  decomposition  of 
this  function  is  shown  in  Figure  8.3. 

Step  3 

To  compare  cognitive  task  demand  on  the  JSTARS  prototype  and 
objective  JSTARS,  a  job  assessment  method  that  included  cognitive 
skills  and  abilities  was  required.  Taxonomies  that  incorporate  knowl¬ 
edge,  skills,  and  abilities  for  many  jobs  exist  in  the  literature  (Muckier, 
Seven,  &  Akman,  1990a),  and  an  evaluation  taxonomy  was  developed 


Figure  8.2.  Functional  job  flow  for  Joint  Surveillance/Target  Acquisition  Radar  System  (JSTARS). 
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specifically  for  C^I  jobs.  The  evaluation  taxonomy  provided  the  hierar¬ 
chy  of  variables  specific  to  the  job  domain  and  is  used  to  structure 
evaluations  and  point  to  measurement  methods. 

The  evaluation  taxonomy  (Muckier,  Seven,  &  Akman,  1990b)  is 
shown  in  Figure  8.4.  For  the  soldier  skills  and  abilities  questions  raised 
for  JSTARS,  variables  in  the  taxonomy  were  selected  from  the  "Soldier 


CMF  LEVEL  VARIABLES 
Training  Requirements 
Accession  Rates 
Retention  Rates 
Paygrade  Distribution 
Career  Field  Structure  &  Management 


MOS  LEVEL  VARIABLES 

Selection  (ASVAB)  Criteria 
Training  Requirements 
Accession  Rates 
Retention  Rates 
Paygrade  Distribution 


JOB  LEVEL  VARIABLES 

•  Critical  Task  Variables 

■  Workload  Demands 

•  Physical  DemarxJs 

•  Skill  Requirements 

■  Adverse  Environments 

•  Organizational  Requirements 

■  Performance  Requirements 

•  Soldier  Characteristics 

"  Educational  Requirements 
^  Educational  Level 
A  Reading  Level 

•  Mental  Category 

■  Physical  Abilities  (PULHES) 

•  Abilities  and  Skills 

A  Cognitive  Abilities 
A  Perceptual  Abilities 

*  Psychomotor  Abilities 

A  Flexibility  and  Coordination 
A  Strength  arxi  Stamina 

"  Work  Attitudes 

*  Work  Orientation 
A  Dependability 

•  Special  Requirements 


Figure  8.4.  Command,  control,  communications,  and  intelligence 
(C^I)  occupational  specialty  evaluation  taxonomy.  CMF  =  Career  Man¬ 
agement  Field;  MOS  =  Military  Occupational  Structure;  ASVAB  = 
Armed  Services  Vocational  Aptitude  Battery;  PULHES  =  classification 
of  physical  abilities  in  terms  of  six  factors:  P  (physical  capacity  or 
stamina),  U  (upper  extremities),  L  (lower  extremities),  H  (hearing  and 
cars),  E  (eyes),  S  (psychiatric).  Each  MOS  has  a  PULHES  profile  de* 
tailing  job  requirements. 
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characteristics:  Abilities  and  skills"  category.  These  were  decomposed  to 
establish  a  core  list  of  abilities  and  skills  to  be  measured.  The  listing 
selected  as  most  relevant  to  C^I,  well-defined  and  empirically  based,  was 
drawn  from  the  work  of  Fleishman  and  Quaintance  (1984)  and  is  shown 
in  Table  8.2  (extensive  discussion  on  the  rationale  for  this  selection  is 
found  in  Muckier  et  al.,  1 990a). 

Modifications  to  the  Fleishman  work  involved  clustering  skills  and 
abilities  according  to  higher-level  logical  aggregates  to  address  questions 
and  obtain  measures  at  different  levels  of  detail.  The  taxonomy  shown 
in  Figure  8.5  is  organized  by  the  skill  and  ability  clusters  that  wens 
devised. 

The  abilities  and  skills  taxonomy  led  to  the  design  and  development 
of  a  flow  diagram  and  scaling  measurement  method,  the  Job  Compari¬ 
son  and  Analysis  Tool  (JCAT).  This  tool  is  based  on  a  technique  origi¬ 
nally  used  by  Mallamad,  Levine,  and  Fleishman  (1980),  but  also  in¬ 
cluded  a  matrix  of  job  functions  to  further  isolate  skill  and  ability 
demands. 

Steps  4,  5,  and  6 

Steps  4,  5,  and  6  for  task  and  workload  assessment  were  combined  for 
the  JSTARS  case  study. 

In  this  single-system  study,  one  information  input  condition  was 
assumed  (step  4),  in  which  operators  are  triggered  to  conduct  the  entire 
mission,  defined  as  a  "typical  JSTARS  targeting  and  surveillance  mis¬ 
sion  for  a  corps  sector."  Cognitive  demands  were  assessed  (step  5)  using 
the  JCAT  instrument  with  the  JSTARS  functions.  Other  potential  load¬ 
ing  factors  (environment,  information  conditions,  group  dynamics,  etc.; 
see  Table  8.1)  were  held  constant,  and  the  essential  factor  for  increased 
loading  on  JSTARS  operators  was  the  introduction  of  the  new  equip¬ 
ment.  Thus,  the  model  of  tasks  and  subsequent  workload  (step  6)  is  a 
set  of  quantitative  profiles  of  the  mission  functions  under  two  condi¬ 
tions,  prototype  JSTARS  and  objective  JSTARS,  which  discriminate 
job  demands  for  two  and  three  operator  positions. 

Study  Execution  and  Results 

The  JCAT  instrument  was  used  to  select  and  scale  ability  and  skill 
requirements  for  the  JSTARS  prototype  and  the  objective  system. 


ENTRY  LEVEL  THAINtNG  &  EXPERIENCE  :  MID^LEVEL  HIGH  LEVEL 


Figure.  8.5.  Strip  chart  of  JSTARS  job  demands  from  Job  Comparison  and  Analysis  Tool  (JCAT)  data  table. 
GLO  -  Ground  Liaison  Officer  (prototype  system);  DMCC  -  Deputy  Mission  Crew  Commander  (objective  system). 


Table  8.3.  JCAT  demand  matrix  for  JSTARS  Army  aircrew  positions 
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GLO  -  Ground  Liaison  Officer  TSS  -  Target  Surveillance  Supervisor 

DMCC  -  Deputy  Mission  Cre>w  Commander  ARSM  -  Army  Radar  Systems  Manager 
AST  -  Aerial  Surveillance  Technician  STO  -  Search/Track  Operator 
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JCAT  elicits  judgements  of  ability  and  skill  demands  using  behavior- 
ally  anchored  scales  along  with  a  matrix  of  the  six  Job  functions 
(Figure  8.2). 

JCAT  was  administered  to  six  subject-matter  experts  for  each  job,  and 
profiles  of  job  task  demands  for  each  version  of  JSTARS  were  com¬ 
puted.  Comparative  analyses  were  then  performed  to  determine  the  im¬ 
pact  of  any  profile  mismatches. 

Table  8.3  shows  sample  results  from  the  JSTARS  JCAT  profiles. 
Numerical  values  in  the  matrix  indicate  demand  level  (high,  medium, 
low)  for  the  skill  and  ability  clusters  for  operator  positions  in  each  sys¬ 
tem.  (Ranges  arc  taken  from  the  behavioral  anchors  validated  in  previ¬ 
ous  research.)  For  the  GLO  (ground  liaison  operator)  position,  commu¬ 
nication  skills  present  the  highest  demand  (5.83)  for  the  prototype 
system.  In  the  objective  system  (for  which  the  job  position  title  was 
changed  to  DMCC,  deputy  mission  crew  commander),  communication 
demand  increases  (6.12).  The  tabular  data  for  the  GLO-DMCC  compari¬ 
son  are  shown  in  the  strip  chart  display  in  Figure  8.5. 

Using  the  high-demand  skill  and  ability  clusters  identified  in  the  pro¬ 
files,  JCAT  data  were  further  analyzed  to  determine  the  source  of  load¬ 
ing  from  two  aspects:  the  underlying  skill(s)  or  ability(s)  within  the 
cluster(s)  responsible  for  high  demand,  and  the  function  and  task  arca(s) 
where  the  high  demand  was  indicated.  Tables  8.4  and  8.5  show  the  data 
for  GLO-DMCC  comparisons.  Together  these  data  form  a  picture  or 
profile  of  the  job  and  indicate  that  only  moderate  to  highly  experienced 
operators  should  be  considered — not  entry  level  personnel  for  the  air¬ 
crew  (detailed  discussion  and  full  data  tables  for  the  JSTARS  positions 
arc  found  in  Knapp,  1994).  The  communications,  conceptual,  reason¬ 
ing,  speed-loaded,  and  auditory  clusters  arc  key  to  workload  and  must  be 
considered  in  selecting  and  training  these  operators. 

In  general,  most  requirements  for  the  objective  system  exceeded  those 
for  the  prototype,  so  workload  is  best  absorbed  by  a  third  operator  (or 
additional  automation)  for  future  missions.  The  increase  involves  com¬ 
munications  skills  and  auditory  ability  for  over  half  of  the  mission 
functions  (planning,  briefing,  on-station,  debriefing),  while  increased 
cognitive  demands  (time  sharing,  inductive  and  deductive  reasoning, 
problem  sensitivity,  etc.)  are  evident  mostly  during  the  on-station  mis¬ 
sion  operations.  For  this  reason,  automation  as  a  design  alternative  may 
be  difficult.  Off-loading  of  communications  and  auditory  functions  is 
better  addressed  by  increasing  personnel  proficiency  and  ensuring  that 


Table  8.4.  Skill  and  ability  demands  by  JSTARS  mission  function 


POST  MISSION 
DEBRIEF/ 
OFF-STATION 

DMCC 

5.87 

3.69 

4.41 

2.90 

3.14 

OOE 

2.29 

2.00 

GLO 

5.37 

3.72 

3.89 

1.99 

2.04 

2.66 

1.52 

1.50 

ON-STATION 

OMCC 

OOS 

4.62 

4.50 

4.50 

3.14 

5.17 

3.14 

2.75 

GLO 

4.95 

4.37 

4.03 

4.43 

OO 

CNJ 

c\i 

4.44 

2.19 

1.86 

OUTBOUND 

OMCC 

4.12 

3.31 

2.50 

3.90 

3.07 

4.83 

3.14 

2.60 

GLO 

3.58 

2.99 

1.60 

2.86 

2.09 

3.99 

2.19 

1.76 

PREFLIGHT 

DMCC 

4.12 

2.88 

2.25 

3.70 

zoe 

4.50 

3.14 

2.45 

GLO 

99E 

2.37 

1.44 

2.46 

2.09 

3.88 

2.19 

1.66 

BRIEF 

DMCC 

5.87 

3.56 

3.58 

2.80 

2.86 

3.00 

1.86 

1.60 

GLO 

5.37 

2.51 

2.44 

1.99 

1.94 

2.66 

1.28 

1.09 

MISSION 

PLANNING 

DMCC 

5.87 

3.94 

4.67 

3.60 

2.79 

3.33 

1.93 

1.60 

GLO 

4.04 

3.60 

3.60 

2.86 

2.04 

2.66 

1.33 

1.09 

SKILL/ABILITY 

CLUSTER 

Communication 

Conceptual 

Reasoning 

Speed-Loaded 

Visual 

Auditory 

Psychomotor 

Gross  Motor 

GLO  •  Ground  Liaison  Officer;  DMCC  -  Deputy  Mission  Crew  Commander 


Table  8.5.  Decomposition  of  critical  JCAT  clusters  for  JSTARS  deputy  mission 
crew  commander  (DMCC) 
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other  nondemanding  mission  functions  (preflight  duties,  aviation- 
specific  duties)  are  handled  by  other  aircrew  personnel. 

TASK  AND  WORKLOAD  DEMANDS 

FOR  ARMY  COMMAND  AND  CONTROL  STAFF 

A  more  comprehensive  task  and  workload  analysis  using  the  six  steps 
detailed  above  is  currently  under  way.  The  objective  is  to  evaluate 
whether  soldiers  in  an  Army  command  and  control  (C^)  staff,  which 
supports  brigade  and  division  commanders,  can  perform  adequately  with 
proposed  new  automation  tools  during  on-the-move  operations  and  in 
distributed  communications  environments.  Command  staff  support 
groups  are  now  set  to  be  replaced  by  smaller,  more  mobile  support 
teams  who  will  share  and  analyze  digitized  information  more  autono¬ 
mously,  rather  than  hovering  over  a  shared  map  board  and  routinely 
conversing  in  person. 

The  variables  of  Table  8.1,  encompassing  a  range  of  mission  condi¬ 
tions,  information  conditions,  personnel,  and  environmental  conditions, 
are  being  assessed  using  a  combination  of  new  measurement  and  model¬ 
ling  techniques.  The  goal  is  to  quantify  the  impact  of  all  variables 
listed,  singularly  and  in  combination,  and  to  differentiate  the  command 
staff  job  demands  in  current  and  proposed  tactical  environments.  The 
analysis  has  begun  with  the  development  of  a  work  flow  model,  shown 
in  Figure  8.6.  An  underlying  assumption  is  that,  regardless  of  job  con¬ 
ditions  (new  technology,  increased  battlefield  tempo,  configuration  of 
C^  staff  personnel,  etc.),  the  staff  functions  to  be  performed  are  invari¬ 
ant  and  consist  of  a  basic  functional  flow  of  information  input  tasks 
(acknowledge  data,  compare  to  "picture"),  information-processing  tasks 
(estimate  impact  of  new  data,  recommend  changes  to  plans  and  orders, 
etc.),  and  output  tasks  (adjust  plans,  issue  orders  and  directives). 

What  defines  the  workload  is  the  nature  and  pace  of  information 
within  the  work  flow,  the  working  conditions,  and  personnel  capabili¬ 
ties  and  dynamics.  Incoming  information  is  the  trigger  to  processing 
and  action,  and  information  events  account  for  demand  on  operator  re¬ 
sources.  In  a  simplistic  example.  Figure  8.7  shows  one  information 
event,  "Firing  battery  down"  (incoming  data  to  a  fire  support  element 
staff  operator  that  an  outlying  firing  battery  is  out),  and  how  this  event 
triggers  a  scries  of  tasks  and  skill  requirements  at  varying  levels 


Figure  8.6.  Generic  work  flow  for  Army  command  and  control  (C“)  staff. 


parentheses  refer  to  skills  and  abilities  list  of  Table  8.2. 
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of  processing  complexity.  For  example,  the  “Compare  to  picture"  task 
involves  detection  and  discrimination  skills,  including  visualization  and 
speed  of  closure  (refer  to  the  skills  and  abilities  listing  in  Table  8.2). 

The  next  step  in  workload  estimation  for  this  single  information 
event  is  to  assign  demand  estimates  for  the  skills  triggered.  Separate 
information  events  within  and  between  staff  sections  could  be  compared 
at  this  point  to  get  a  rough  estimation  of  differing  workload;  however,  a 
more  operationally  realistic  picture  of  the  mission  is  obtained  using 
additional  parameter  values  for  sequential  and  concurrent  information 
events,  different  information  event  rates,  and  environmental,  automation 
technology,  and  group  dynamics  variables  listed  in  Table  8.1.  This  ne- 
suits  in  a  library  of  mission  profiles,  which  can  be  executed  in  a 
task  network  and  resource  demand  computational  model  or  models 
(e.g.,  ARL’s  CREWCUT,  1993). 

To  determine  the  parameter  values  to  populate  the  mission  profiles, 
detailed  data  must  be  elicited  from  experts  on  the  current  and  ex¬ 
pected  distribution  of  information  event  typ)es  and  rates,  and  on  the 
characteristics  of  the  automation  technology  proposed.  Research  will  be 
required  to  develop  and  assign  scale  values  for  the  personnel  and  envi¬ 
ronmental  variables,  such  as  the  knowledge,  skill,  and  abilities  demands 
for  each  mission  and  staff  section.  Model  runs  then  produce  output  re¬ 
ports  that  show  points  of  overload  in  task  demands  under  different  vari¬ 
able  conditions.  These  are  the  data  from  which  the  function  allocation 
decisions  will  be  made. 


SUMMARY 

Function  allocation  decisions  for  C^I  systems  depend  on  sound  task 
and  workload  analysis  to  provide  quantitative  profiles  of  the  jobs  being 
designed.  Since  the  tasks  in  these  systems  are  mainly  cognitive  in  na¬ 
ture  and  are  linked  to  control  of  automated  systems,  a  systematic  ap¬ 
proach  to  the  analysis  and  measurement  of  Job  demand  is  essential.  The 
work  presented  in  this  paper  has  illustrated  one  such  method  being  used 
for  new  Army  C^I  systems,  which  shows  considerable  success  in  meet¬ 
ing  the  challenge  of  measuring  and  evaluating  the  information¬ 
processing  tasks  characteristic  of  these  systems. 
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ADAPTIVE  FUNCTION  ALLOCATION 
FOR  SITUATION  ASSESSMENT  AND 
ACTION  PLANNING  IN  C'  SYSTEMS 

W.  Berheide,  H.  Distelmaier,  and  B.  Dortng 


fniprovenients  in  sensor  and  effector  technologies  in  modern 
command,  control,  and  communication  (C^)  systems  increase 
the  amount  and  complexity  of  information  to  he  processed  and 
greatly  decrease  the  time  available  to  process  that  informa¬ 
tion.  Supporting  the  operators  of  these  systems  by  means  of 
intelligent  and  adaptive  human-machine  interfaces  can  at 
least  partly  handle  this  situation.  This  approach  requires  a 
situation-specific  allocation  of  functions  betw  een  operator 
and  machine  system  components.  This  paper  starts  with  a 
general  description  of  human  tasks  in  military  decision  situa¬ 
tions.  Principles  for  supporting  human  decision  making  in 
.systems  are  presented.  The  support  concept  of  a  knowiedge- 
based  user  assistant  that  comprises  a  dialogue  monitor,  a 
situation  monitor,  an  action  planner,  and  a  display  manager 
is  explained  in  detail.  An  object-oriented  implementation  and 
prototyping  of  the  assistant  based  on  a  hierarchical  function 
analysis  is  explained;  tasks  of  the  principle  warfare  officer  in 
a  Navy  combat  information  center  are  used  as  an  example. 


INTRODUCTION 

Improvements  in  sensor  and  elTeclor  technology  in  mexJem  command, 
control,  and  communication  (C^)  systems  increase  the  amount  and  com¬ 
plexity  of  information  to  be  prcKesscd  and  greatly  decrease  the  time 
available  to  treat  this  information.  This  situation  can  be  handled  partly 
by  increasing  processing  speed  through  a  higher  degree  of  automation. 
But  human  decision  makers  cannot  be  replaced  in  military  .systems.  In 
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unforeseen  and  emergency  situations  in  complex  military  environments, 
a  higher  degree  of  automation  leads  to  reduced  decision  time  and  in¬ 
creased  information  complexity,  which  results  in  an  intolerable  work¬ 
load  level  for  human  operators  and  decision  makers.  The  consequence  is 
increased  human  errors  and  reduced  overall  system  performance.  Support¬ 
ing  the  operators  (users)  through  intelligent  and  adaptive  human - 
machine  interfaces  can  help  reduce  these  problems.  This  approach  re¬ 
quires  situation-specific  allocation  of  functions  between  system  users 
and  machine  system  components. 

Information-processing  functions  normally  performed  in  systems 
are  situation  assessment,  action  planning,  action  command,  and  check¬ 
ing  of  action  accomplishment.  These  functions  describe  the  course  of 
action  in  military  decision  situations.  Viewing  such  situations  from  a 
behavioral  perspective,  Wohl  (1981)  identified  generic  elements  that 
describe  the  military  decision-making  process  and  constitute  the  basis  of 
his  SHOR  model.  These  elements  are:  stimulus,  hypothesis,  option, 
and  response  (Figure  9.1). 

The  stimulus  element  ineludes  data  collection,  correlation  aggrega¬ 
tion,  and  recall  activities.  In  a  tactical  air-threat  situation  on  a  ship,  such 
data  are,  for  example,  distance,  bearing,  and  speed  of  a  target,  and  sensor 
and  weapon  range  of  own  ship.  Often  those  data  are  available  only  se¬ 
quentially  over  time,  and  the  operator  must  store  them  in  memory.  On 
the  basis  of  the  collected  information,  the  decision  maker  creates  a  hy¬ 
pothesis  concerning  the  actual  threat  situation.  When  new  data  arc  re¬ 
ceived,  for  example,  new  target  data  such  as  its  classification  and  sensor 
and  weapon  range,  the  evaluation  of  the  initial  hypothesis  results  in  its 
confirmation  or  rejection.  In  the  latter  case,  a  new  hypothesis  will  be 
generated  considering  the  newly  available  data.  Often,  due  to  the  uncer¬ 
tainty  of  data,  hypotheses  can  be  generated  only  with  certain  probabili¬ 
ties.  Then,  one  hypothesis  must  be  selected  as  the  most  likely  cause  of 
the  data.  For  each  hypothesis,  the  decision  maker  must  generate  and 
evaluate  alternative  options  for  solving  the  problem.  The  evaluation  has 
to  consider  option  effectiveness  with  regard  to  mission  accomplishment 
and  system  safety.  The  most  appropriate  option  is  selected.  On  the  basis 
of  the  selected  option,  the  decision  maker  takes  action  that  includes 
planning,  organizing,  and  executing  the  response  to  the  problem  situa¬ 
tion. 

When  accomplishing  these  decision-making  functions,  the  human 
decision  maker  has  to  deal  with  two  types  of  uncertainty  (Wohl,  1981): 


Triggering  Event  (Deadline,  Policy,  Enemy  Action,  New  Data,  etc.) 


Figure  9.1.  Elements  and  functions  of  the  military  decision  process.  From  “Force  management  decision  require¬ 
ments  for  air  force  tactical  command  and  control,”  by  J.  G.  Wohl,  1981,  IEEE  Transactions  on  Systems,  Man,  and 
Cybernetics,  1 1(9),  p.  626,  Fig.  8.  Copyright  ©  1981  IEEE.  Reprinted  with  permission. 
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(1)  information  input  uncertainty,  which  creates  the  need  for  hypothesis 
generation  and  evaluation;  and  (2)  consequence-of-aetion  uncertainty, 
which  creates  the  need  for  option  generation  and  evaluation.  Generally,  a 
human  decision  maker  has  specific  deficiencies  in  performing  these  ele¬ 
mentary  functions  due  to  human  capabilities  and  limitations  (Anderson, 
1988;  Wiekens,  1984).  Edwards  (1990)  points  out  that  such  deficiencies 
are  especially  likely  in  pilot  performance.  Comprehensive  deficiency 
listings  have  been  compiled  for  the  design  of  decision  support  systems 
(Cohen,  Thompson,  &  Chinnis,  1985;  Sage,  1991).  Only  some  exam¬ 
ples  will  be  given  here. 

In  performing  the  function  “Gather  data,”  for  example,  human  deci¬ 
sion  makers  tend  to  use  only  easily  available  data;  they  consider  only  a 
few  samples  of  data.  In  performing  the  functions  “Create  and  evaluate 
hypothesis,”  they  are  likely  to  ignore  data  that  disconfirm  the  hypothe¬ 
sis  currently  being  considered,  tend  to  generate  recently  used  hypotheses 
over  again,  and  have  difficulty  assessing  probabilities.  In  performing  the 
functions  “Create,  evaluate,  and  select  option,”  humans  segment  com¬ 
plex  options  into  “natural”  components  and  treat  the  elements  as  if  they 
were  independent  choices,  which  leads  to  suboptimal  portfolios.  They 
have  difficulty  recalling  all  situation-relevant  options  and  under  time 
pressure  tend  to  give  more  weight  to  negative  evidence  concerning  alter¬ 
natives  than  to  positive  evidence. 

CONCEPT  FOR  SUPPORTING 
HUMAN  DECISION  MAKING 

To  overcome  the  deficiencies  mentioned  above  and  to  support  the 
human  operator  in  decision  making  in  complex  systems,  adaptive  aiding 
concepts  have  been  developed  (Rouse,  Geddes,  &  Curry,  1988;  Rouse, 
1991).  In  recent  years,  these  concepts  have  been  applied  mainly  in  sup¬ 
port  for  aircraft  pilots  (Amalberti  &  Deblon,  1992;  Banks  &  Lizza, 
1991;  Dudek,  1990;  Rouse,  Geddes,  &  Hammer,  1990;  Wittig  & 
Onken,  1992).  Basic  to  these  concepts  is  the  philosophy  that  total 
automation  cannot  be  the  utmost  objective  of  system  development.  The 
consequence  of  this  philosophy  is  that  the  role  of  the  operator  as  deci¬ 
sion  maker  has  to  be  accepted  prior  to  system  design.  This  is  important 
because  the  overall  performance  of  complex  systems  depends  heavily  on 
human  performance,  particularly  when  abnormal  and  emergency  situa¬ 
tions  arise. 
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Figure  9.2.  Structure  of  a  knowledge-based  user  interface. 
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The  operator  should  be  involved  in  the  decision-making  process  as 
long  as  his  or  her  abilities  are  sufficient.  An  aid  is  provided  only  to 
enhance  human  abilities  (e.g.,  in  detecting  and  evaluating  complex  pat¬ 
terns  or  reacting  to  unforeseen  events),  to  overcome  human  limitations, 
and  to  complement  individual  human  preferences. 

This  idealistic  concept  is  based  on  the  philosophy  of  human-centered 
automation  and  envisions  a  computerized  assistant  that  behaves  like  a 
human  partner  to  the  operator,  that  is,  it  can  be  commissioned  and 
automatically  takes  over  tasks.  Like  the  operator,  the  assistant  monitors 
states  of  the  system  and  the  environment  and,  in  parallel,  the  actions  of 
the  operator  (Figure  9.2).  If  it  encounters  emergency  situations  or  inap¬ 
propriate  operator  behavior,  it  automatically  performs  some  operator 
functions.  Faulty  behavior  of  the  operator  will  be  identified,  announced, 
and,  if  there  is  no  reaction  from  the  or>erator,  possibly  corrected  by  the 
assistant.  This  concept  prefers  the  idea  of  variable  rather  than  fixed  auto¬ 
mation.  The  automation  is  related  to  the  classic  problem  of  allocation  of 
functions  between  humans  and  machines,  but,  in  this  approach,  automa¬ 
tion  is  adapted  to  different  situations,  missions,  tasks,  etc. 

One  of  the  key  issues  in  adaptive  automation  concerns  the  method  by 
which  adaptation  is  accomplished.  Two  main  approaches  can  be 
distinguished  (Rouse,  1991;  Parasuraman,  Bahri,  Deaton,  Morrison,  & 
Barnes,  1992).  The  operator-driven  approach  considers  the  actual  state  of 
the  operator,  which  can  be  identified  by  measuring  and/or  modelling 
operator  performance.  The  event-driven  approach  considers  critical 
situation  events  that  arise  during  a  mission,  for  example,  by  state 
changes  of  the  tactical  situation  or  the  system. 

Most  adaptive  systems  are  based  on  the  event-driven  approach,  which 
later  can  be  supplemented  by  the  operator-driven  approach.  Therefore,  wc 
also  used  the  first  approach  in  initiating  development  of  a  knowledge- 
based  user  assistant.  In  this  method,  the  implementation  of  automation 
is  linked  to  the  occurrence  of  specific  tactical  events.  Such  an  automa¬ 
tion  method  is  inherently  flexible  because  it  can  be  tied  to  current  mili¬ 
tary  doctrine  during  mission  planning  (Parasuraman  ct  al.,  1992). 

THE  KNOWLEDGE-BASED  USER  ASSISTANT  (KBUA) 

A  concept  for  an  aiding  system  to  support  the  decision-making  task 
of  the  principal  warfare  officer  (PWO)  in  Navy  combat  information 


Select  threatening 
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! 


Figure  9.3.  Hierarchy  of  operator  support  functions  (partial)  for  support  of  the  principal  warfare  officer  in  supervis¬ 
ing  automatic  threat  evaulation  and  weapon  assignment  (TEWA)  in  anti-air  warfare  (AAW). 
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centers  (CICs)  on  board  ships  has  been  developed.  In  general,  CIC  func¬ 
tions  to  be  performed  by  the  PWO  are  situation  assessment,  action 
planning,  action  command,  and  checking  of  action  accomplishment. 
During  a  mission,  assessments  are  made  about  different  aspects  of  situa¬ 
tions,  including  states  of  the  tactical  and  physical  environment,  states  of 
personnel  and  the  logistic  supply,  and  states  of  the  ship  and  its  subsys¬ 
tems  (e.g.,  sensor,  effector,  and  propulsion  subsystems,  etc.). 

At  present,  we  are  working  on  an  aiding  concept  that  supports  the 
operator  (i.e.,  the  PWO)  especially  in  threat  evaluation  and  weapon 
assignment  (TEWA)  in  antiair  warfare  situations.  To  identify  functions 
for  supporting  the  operator  during  these  situations,  a  top-down  function 
analysis  (Beevis,  1992)  has  been  performed.  The  resulting  functional 
hierarchy  contains  different  levels  with  functions  of  decreasing  complex¬ 
ity,  part  of  which  are  shown  in  Figure  9.3.  In  this  figure,  the  decompo¬ 
sition  proceeds  from  left  to  right.  For  instance,  the  high-level  function 
“Supervise  target  selection”  has  been  decomposed  into  subfunctions 
such  as  “Evaluate  TEWA  target  selection,”  “Support  changing  TEWA 
target  selection,”  and  “Confirm  TEWA  target  selection.”  The  decom¬ 
position  of  the  subfunction  “Evaluate  TEWA  target  selection”  continues 
with  its  subfunctions  “Select  threatening  target”  and  “Compare  target 
selection.” 

As  part  of  an  adaptive  aiding  concept,  each  of  the  identified  operator 
support  functions  in  Figure  9.3  is  conceived  as  consisting  of  four  func¬ 
tional  components:  “Monitor  situation,”  “Monitor  dialogue,”  “Select 
action,”  and  “Specify  display.”  Figure  9.4  depicts  the  general  structure 
of  an  operator  support  function  with  its  four  components  and  their  in¬ 
put/output  relations.  The  inputs  and  outputs  of  the  generalized  operator 
support  function  in  Figure  9.4  have  the  same  generalized  categories  as 
that  of  the  knowledge-based  user  assistant  (KBUA)  in  Figure  9.2,  that 
is,  dialogue  commands  and  situation  data  inputs,  and  system  function 
commands  and  display  configuration  outputs.  Every  function  thus  con¬ 
tributes  to  all  aspects  of  the  KBUA.  For  instance,  in  reaction  to  the 
detection  of  an  environmental  situation  event,  any  function  on  any  func¬ 
tion  level  could  give  prompts  both  to  the  controlled  TEWA  process  and 
to  a  corresponding  display  configuration  on  the  user  interface. 

The  functional  component  “Monitor  situation”  of  an  operator  support 
function  supports  the  first  two  steps  of  human  decision  making — data 
collection  and  hypx)theses  generation  (Figure  9.1).  This  component 
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Figure  9.4.  General  structure  of  an  operator  support  function. 
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reviews  situation-relevant  data  and  decides  about  the  current  state  of 
affairs.  If  a  situation  event  has  been  detected,  it  is  given  to  the  func¬ 
tional  component  “Select  action”  to  perform  appropriate  actions.  The 
component  “Select  action”  is  to  support  the  operator  in  performing  the 
third  step  of  human  decision  making  (Figure  9.1) — option  generation, 
evaluation,  and  selection — by  identifying  all  actions  that  are  necessary 
and  possible  for  responding  to  the  current  situation  event.  Normally,  all 
actions  identified  and  evaluated  are  provided  by  the  “Specify  display” 
component  to  the  PWO,  who  decides  which  action  should  be  taken.  In 
critical  threat  situations,  for  example,  incoming  air-to-surface  missiles 
detected  within  critical  envelopes,  a  reaction  process  is  executed  without 
PWO  intervention.  In  this  case,  the  component  “Select  action”  generates 
commands  for  required  fast  automatic  system  functions  (Figure  9.4). 
The  resulting  decision  about  this  automatic  reaction  is  also  presented  to 
the  PWO  via  the  “Specify  display”  component.  For  each  situation,  the 
appropriate  display  and  dialogue  elements  are  stored  as  display  resources. 
To  assist  the  operator  in  an  actual  situation,  the  component  “Specify 
display”  activates  the  corresponding  elements  and  presents  them  via  the 
graphical  user  interface. 

The  operator  dialogue  commands  are  monitored  by  the  functional 
component  “Monitor  dialogue,”  which  helps  the  operator  avoid  negative 
consequences  of  inappropriate  commands.  This  component  compares  the 
actual  dialogue  commands  with  those  that  are  permitted  given  the 
present  situation  and  sends  the  resulting  dialogue  events  to  the  “Select 
action”  component.  If  an  actual  dialogue  command  does  not  correspond 
to  what  is  permitted,  the  component  “Monitor  dialogue”  blocks  its 
execution  and  provides  a  prompt  to  the  PWO  via  the  graphical  user 
interface. 

For  each  operator  support  function,  three  different  successive  states 
have  been  defined:  inactive,  monitoring,  or  active.  When  a  function  is 
inactive,  none  of  its  functional  components  is  in  operation.  When  a 
function  is  in  the  monitoring  state,  only  the  two  functional  components 
“Monitor  situation”  and  “Monitor  dialogue”  are  operating  and  no  output 
is  generated.  In  the  active  state,  all  of  the  four  functional  components 
shown  in  Figure  9.4  are  in  operation.  An  inactive  function  in  the  func¬ 
tion  hierarchy  will  be  transferred  automatically  into  the  monitoring  state 
if  its  encompassing  function  on  the  next  higher  level  of  the  hierarchy  is 
active  (Figure  9.5).  A  function  will  be  active  if  the  monitoring 


Figure  9.5.  Example  of  operator  support  functions  and  their  states  during  support  of  the  principal  warfare  officer  in 
supervising  target  selection  during  automatic  threat  evaluation  and  weapon  assignment  (TEWA)  in  anti-air  warfare 
(AAW). 
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components  detect  an  activation  event.  The  function  changes  its  state 
from  active  to  monitoring  if  the  monitoring  components  detect  a  deacti¬ 
vation  event. 

The  example  shown  in  Figure  9.5  represents  a  situation  in  whieh  the 
KBUA  supports  the  PWO  in  supervising  target  seleetion  during  an 
automatic  TEWA.  In  this  ease,  the  KBUA  decided  that  a  target  should  be 
deleted  from  the  list  of  engageable  targets.  In  the  activated  operator  sup¬ 
port  function  “Support  removing  TEWA  target,”  the  functional  compo¬ 
nent  “Specify  display”  gives  the  reason  for  this  decision  via  the  graphi¬ 
cal  user  interface  to  the  PWO,  who  has  to  agree. 

If  the  PWO  acknowledges  the  KBUA  decision  by  pressing  the 
“Delete”  button  at  the  user  interface,  the  function  “Delete  TEWA  tar¬ 
get,”  which  is  now  in  the  monitoring  state,  will  be  activated  and  a  dele¬ 
tion  command  for  the  TEWA  function  will  be  generated.  The  PWO  ean 
also  decide  to  delay  the  engagement  by  pressing  the  “Delay”  button. 
Then  the  operator  support  function  “Delay  TEWA  target,”  whieh  is  in 
the  monitoring  state,  will  be  activated  and  a  delay  command  will  be 
given  to  the  TEWA  system  process.  After  sending  the  command,  the 
function  itself  will  be  stopped  and  the  encompassing  function  “Support 
removing  TEWA  target”  eventually  will  be  deactivated. 

The  hierarchically  structured  operator  support  functions  (Figure  9.3), 
together  with  their  four  functional  components  “Monitor  situation,” 
“Monitor  dialogue,”  “Select  action,”  and  “Specify  display”  (Figure  9.4), 
constitute  the  concrete  functional  model  of  the  KBUA  shown  in  Figure 
9,2  for  a  specific  application,  in  this  case  for  supporting  the  operator  in 
antiair  warfare  situations.  The  event-oriented  control  of  each  function 
described  here  enables  the  KBUA  to  react  to  environmental  situations. 
Depending  on  an  actual  event,  a  subfunction  for  controlling  automatic 
system  functions  or  for  prompting  required  operator  actions  will  be 
activated.  In  this  way,  the  support  concept  allows  a  situation-dependent 
activation  of  automatic  system  functions  or  required  operator  actions  in 
an  adaptive  manner  for  every  function.  The  great  adaptability  of  the 
KBUA  is  seen  in  its  ability  to  react  to  a  broad  variety  of  situations.  It 
should  be  stressed  that  all  of  these  situations  have  to  be  analyzed  and 
functionally  modelled  for  the  concrete  support  system. 

Each  operator  support  function  in  the  function  hierarchy  has  to  be 
described  in  a  form  that  contains  function-related  specifications;  for  ex¬ 
ample,  activation  events,  deactivation  events,  information-processing 
procedures,  control  commands  for  system  functions  accomplished  auto- 
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matically,  relevant  display  information  and  action  requirements  for  the 
operator,  display  elements  for  presenting  the  information  and  possible 
actions  on  the  graphical  user  interface,  and  subfunetions. 

OBJECT-ORIENTED  IMPLEMENTATION  OF  THE  KBUA 

For  supporting  the  implementation  of  the  functional  KBUA  model 
and  prototyping  the  human-machine  interface  of  the  PWO,  we  applied 
an  object-oriented  approach  (e.g.,  Coad  &  Yourdon,  1991;  Embley, 
Kurtz,  &  Woodfield,  1992;  Rumbaugh,  Blaha,  Premerlani,  Eddy,  & 
Lorensen,  1991)  that  results  in  an  object-oriented  KBUA  model.  An 
object  is  considered  to  be  an  encapsulated  entity  that  accepts  messages 
for  activating  its  processes  and  changing  its  state,  and  sends  messages  to 
other  objects.  The  central  part  of  this  object-oriented  KBUA  model  con¬ 
sists  of  a  hierarchy  of  objects  analogous  to  the  function  hierarchy 
(Figure  9.3).  Just  as  every  encompassing  function  consists  of  subfune¬ 
tions,  every  aggregate  object  consists  of  a  set  of  subobjeets.  As  with  a 
function,  three  different  states  of  an  object  can  be  distinguished:  inac¬ 
tive,  monitoring,  and  active.  Figure  9.6  depicts  an  object  with  its  states, 
state  transitions,  and  the  messages  it  accepts  and  delivers. 

As  in  the  generalized  function  input  and  output  shown  in  Figure  9.4, 
an  object  receives  messages  with  situation  data  and  dialogue  commands 
and  sends  messages  with  display  configurations  and  commands  for 
system  functions  (Figure  9.6).  It  also  receives  enabling  and  disabling 
messages  from  its  aggregate  object  and  sends  enabling  and  disabling 
messages  to  its  subobjeets.  The  enabling  and  disabling  messages 
received  cause  the  corresponding  events  within  the  object.  Messages  in 
the  form  of  situation  data  and  dialogue  commands  cause  activation  and 
deactivation  events  within  the  object.  As  schematized  in  Figure  9.6, 
these  triggering  events  cause  state  transitions  with  accompanying 
actions. 

In  general,  a  functional  object  has  data  and  procedural  aspects;  that  is, 
it  is  characterized  by  data  (properties)  and  will  activate  procedures.  Data 
are  peculiar  to  each  object,  for  example,  its  state.  PrcKcdures  specify  the 
functional  components  of  an  operator  support  function  as  deseribed 
above,  that  is,  “Monitor  situation,”  “Monitor  dialogue,”  “Select  action,” 
and  “Specify  display.”  As  with  an  operator  support  function,  in  the 
monitoring  state  of  an  object,  “Monitor  situation”  and  “Monitor  dia¬ 
logue”  piXKcdurcs  arc  in  operation.  In  the  active  state  of  an  object, 
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Figure  9.6.  Messages  and  state  transition  structure  of  an  object. 
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“Select  action’’  and  “Specify  display’’  procedures  will  also  be  performed. 
“Monitor  situation’’  and  “Monitor  dialogue’’  procedures  generate  activa¬ 
tion  and  deactivation  events  by  interpreting  situation  data  and  dialogue 
commands.  They  arc  specified  as  rules  describing  tbc  event  conditions. 
“Select  action”  procedures  arc  represented  by  information-processing 
algorithms  that  generate  commands  for  system  functions  and  data  used 
internally. 

“Specify  display”  pnKcdurcs  arc  implemented  as  a  set  of  control 
commands  that  describe  the  display  configuration  messages.  Tbc  display 
system  deccxlcs  these  messages  and  activates  appropriate  display  ele¬ 
ments  (c.g.,  windows,  icons,  menus,  buttons,  etc.).  These  display  ele¬ 
ments  will  be  added  to  the  interactive  graphical  user  interface,  for  in¬ 
stance,  to  tbc  display  configuration  already  provided  by  activation  of 
parallel  or  bigber-lcvcl  objects.  When  objects  arc  suspended  or  termi¬ 
nated,  tbc  affiliated  information  and  action  alternatives  arc  removed  from 
tbc  interface. 

Figure  9.7  shows  the  resulting  structure  of  tbc  implemented  object- 
oriented  KBUA  model.  The  object  hierarchy  presented  is  equivalent  to 
the  structure  of  the  functional  hierarchy  of  operator  support  functions 
shown  in  Figure  9.3.  Each  object  presented  in  Figure  9.7  behaves  as 
described  above.  In  this  way,  every  object  contributes  to  the  overall 
behavior  of  the  knowledge-based  user  assistant  depicted  in  I^igurc  9.2. 
An  advantage  of  this  object-oriented  KBUA  model  is  its  easy  adaptation 
to  additional  requirements.  More  objects  and  subobjects  can  be  added  for 
additional  situation  events  and  their  corresponding  functions  and  sub¬ 
functions  identified  during  the  analysis. 

A  prerequisite  for  constructing  this  object-oriented  KBUA  model  is  a 
thorough  identification  of  the  functional  model,  that  is,  all  relevant 
events  and  initiated  functions,  and  tbc  analysis  of  those  functions  aixl 
their  affiliated  information/action  requirements.  These  items  can  be  iden¬ 
tified  by  an  analysis  that  starts  with  the  mission  of  the  system  and  its 
planned  operations.  But  the  analysis  should  be  pcrfomicd  anyhow  when 
human-machine  interfaces  arc  designed  and  prototyped  (Beevis,  1992). 
The  functional  and  object-oriented  KBUA  models  described  above  serve 
as  conceptual  frameworks  for  the  analysis  in  the  problem  domain.  They 
already  contain  all  classes  of  subobjccls  mentioned  along  with  their 
necessary  properties  and  methods.  In  addition,  the  object-oriented  mcxlel 
resulting  from  tbc  analysis  represents  a  design  description  of  the  KBUA 
that  serves  as  a  basis  for  its  implementation. 


Figure  9.7.  Principle  of  the  object  hierarchy. 
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THE  PROTOTYPING  APPROACH 

A  prototyping  approach  will  be  applied  in  developing  the  human- 
machine  interface  of  the  PWO  and  using  it  as  a  demonstrator.  This  ap¬ 
proach  supports  the  trend  in  the  development  of  computer  applications 
of  shifting  power  from  specially  trained  programmers  to  domain  experts 
and  users.  This  trend  will  also  force  development  organizations  to  bring 
users  into  system  design  as  early  as  possible  and  finally  accept  proto¬ 
typing  as  a  legitimate  technique. 

Prototyping  is  the  construction  of  a  (software)  product  by  iterative 
design,  in  which  a  user  interface  is  included  from  the  beginning  and,  in 
most  cases,  a  simulator  of  a  controlled  or  monitored  system  is  incorpo¬ 
rated.  The  prototyping  approach  does  not  mean  building  and  testing  a 
prototype  and  then  creating  a  new  system  with  another  language  and 
another  hardware  system  corresponding  to  this  prototype.  Here,  the  pro¬ 
totype  itself  becomes  the  system.  Prototyping  is  an  iterative  and  incre¬ 
mental  approach  to  the  construction  of  systems. 

The  requirements  for  many  military  systems  are  not  clear  at  the  be¬ 
ginning.  This  is  especially  true  for  the  design  of  user  interfaces.  In  the 
prototyping  approach,  one  can  start  with  a  very  simple  design  (e.g.,  an 
existing  design),  let  it  be  evaluated  by  military  users,  and  augment  it 
from  time  to  time  in  an  iterative  manner  with  a  better  version  adapted  to 
new  requirements.  In  this  way,  the  user  can  be  involved  in  very  early 
design  stages,  and  the  role  of  the  user  is  implicit.  Therefore,  the  system 
will  be  better  accepted  by  users,  and  most  requirements  will  be  better 
understood  by  them.  The  prototyping  approach  that  we  apply  starts  with 
a  relatively  simple  mission  and  a  very  simple  function  model  reacting  to 
only  a  few  events. 

We  began  by  describing  a  multithreat  situation  in  an  antiair  warfare 
mission  of  a  ship  and  identifying  relevant  mission  events  and  functions 
of  the  PWO.  The  identified  mission  functions  are  basic  data  for  design¬ 
ing  the  function  hierarchy.  The  conditions  of  relevant  mission  events 
specify  the  rules  of  the  “Monitor  situation”  procedures  of  each  function. 
Further,  information/action  requirements  have  been  identified  for  each 
function  as  a  basis  for  the  “Specify  display”  component.  These  data  are 
used  to  develop  display  layouts  using  the  illustration  and  designing  tool 
MacroMind.  The  layouts  have  been  and  will  be  discussed  with  experi¬ 
enced  users  for  acceptance  and  improvements.  By  decomposing  these 
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layouts  into  their  elementary  units,  it  was  possible  to  identify  required 
display  and  dialogue  elements  of  the  display  manager. 

The  object-oriented  KBUA  model  is  independent  of  a  specific  com¬ 
puter  language  or  implementation  system.  To  implement  the  interface 
demonstrator,  we  installed  the  model  on  a  DEC-VAX  station  with  the 
expert  system  shell  Smart  Elements.  Other  components  of  the  demon¬ 
strator  are  two  pixel -oriented  screens  with  pointing  devices  and  a  key¬ 
board.  The  model  is  implemented  with  those  object-oriented  features  and 
rules  that  Smart  Elements  offers.  The  graphical  output  and  dialogue 
features  of  Smart  Elements  are  used  as  an  interactive  graphical  interface. 
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HUMAN-CENTERED  COCKPIT  DESIGN 
THROUGH  THE  KNOWLEDGE-BASED 
COCKPIT  ASSISTANT  SYSTEM  (CASSY)' 

R.  Onken 


This  paper  presents  basic  requirements  for  cockpit  systems  that 
promote  improved  human-machine  interaction.  Such  an  approach 
is  often  coded  "human-centered  automation"  or  "human/machine 
function  allocation. "  Human-centered  automation  in  its  true  sense 
means  enhancing  flight  safety  and  mission  effectiveness.  The 
time  has  come  when  future  cockpit  systems  no  longer  will  be  de¬ 
signed  on  the  basis  of  vague  specifications  to  achieve  human- 
centered  automation.  Advances  in  technology  make  it  possible 
systematically  to  translate  requirements  for  human-centered  auto¬ 
mation  into  clear-cut  specifications  for  cockpit  systems.  Machine 
functions  should  be  incorporated  that  provide  more  than  just  sup¬ 
port  for  planning  and  plan  execution,  as  emphasized  in  the  past. 
Instead,  the  main  emphasis  should  be  on  autonomous  machine 
situation  assessment  in  parallel  with  the  crew's  situation  assess¬ 
ment  activity,  which  leads  to  better  machine  understanding  of  the 
crew's  real  needs.  The  Cockpit  Assistant  System  de¬ 

veloped  to  meet  these  requirements. 


INTRODUCTION 

Regardless  of  whether  the  applieation  is  eivil  or  military,  the  objeetive 
of  a  flight  mission  is  to  aeeomplish  that  mission  without  loss  of  hu¬ 
man  life  or  equipment.  Thus,  flight  safety  obviously  is  of  paramount 


*  Copyright  R.  Onken.  Reprinted  with  permission. 
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concern.  Every  accident  that  has  occurred,  for  whatever  deplorable  rea¬ 
son,  is  one  accident  too  many. 

Investigations  into  accidents  in  civil  aviation  and  their  causes  provide 
ample  evidence  of  the  fact  that  erratic  human  behavior  is  the  main  con¬ 
tributing  factor  in  about  75  percent  of  all  such  accidents.  It  can  be 
claimed  that  these  human  failures  are  caused  by  some  kind  of  overtax¬ 
ing,*  sometimes  clearly  realized  and  sometimes  not  even  noticed  until  it 
is  too  late.  In  this  context,  overtaxing  is  considered  to  describe  the 
situation  that  arises  when  human  failure  threatens  because  of  inherent 
human  deficiencies  in  sensory,  cognitive,  and  motor  capabilities  and 
performance.  As  automation  in  the  aircraft  cockpit  has  increased,  new 
types  of  situations  have  arisen  that  are  prone  to  latent  overtaxing,  espe¬ 
cially  those  involving  failures  in  situation  awareness  due  to  human 
cognitive  limitations.  Recent  accidents  involving  highly  automated 
civil  transport  aircraft,  which  have  gained  great  public  attention,  provide 
evidence  of  this  trend. 

The  potential  hazard  of  overtaxing  the  cockpit  crew  in  certain  flight 
situations  calls  for  even  more  automation,  which  I  explicitly  want  to 
support  as  the  reasonable  way  to  proceed.  Automation  itself  should  not 
be  blamed  for  potentially  overtaxing  the  crew.  The  question  of  how  to 
automate  does  have  to  be  raised,  however.  The  way  automation  has 
been  pushed  forward  in  the  past  must  be  scrutinized. 

Automation  has  been  advancing  by  respecting  certain  principles  re¬ 
garding  the  role  of  the  human — which  should  by  no  means  be 
changed — and  by  following  a  certain  scheme  of  function  allocation  to 
the  crew,  on  the  one  side,  and  to  technical  components,  the  machine,  on 
the  other.  Figure  10.1  illustrates  the  functions  allocated  currently  to  the 
aircraft  systems  and  those  the  crew  is  trained  to  perform.  There  are  some 
functions  (usually  not  considered  allocated)  that  arc  permanently  turned 
on,  such  as  the  basic  cockpit  instrumentation  and  actuator  machinery 
for  power  amplification,  and  other  functions  that  are  activated  by  the 
crew  and  thus  allocated  to  carry  out  certain  tasks  in  place  of  the  crew. 

Function  allocation  is  not  as  easy  a  task  as  it  might  appear  at  first 
glance.  Major  driving  factors  for  allocating  functions  or  parts  of  func¬ 
tions  to  the  machine  in  one  way  or  another  arc  the  potential  for  reduc- 


*  The  term  overtax  is  used  here  instead  of  the  more  common  term  overload  to 
separate  the  concept  from  associations  with  workload  and  to  include  situa¬ 
tions  where  humans  cannot  cope  because  of  lack  of  abilities. 
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Figure  10. 1.  Flight  guidance  and  control  today. 
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ingcrew  workload — letting  the  machine  do  what  it  can  do  better — and 
demonstration  of  technical  feasibility.  Technical  feasibility  has  often 
seemed  to  be  considered  sufficient  reason  for  automating  certain  func¬ 
tions,  whatever  the  type  of  allocation,  in  the  hope  that  some  kind  of 
overall  system  improvement  and  crew  workload  reduction  will  result. 
To  let  the  machine  do  what  it  seems  to  do  better,  however,  might  lead 
accidentally  to  allocating  certain  functions  to  the  machine  when  parts  of 
these  functions  actually  could  be  carried  out  much  better  by  the  crew. 
As  Billings  (1991)  has  noted:  "While  it  clearly  makes  sense  to  appor¬ 
tion  to  the  man  and  the  system  respectively  those  aspects  of  the  task 
that  each  does  best,  there  are  no  infallible  rules  to  define  these  profi¬ 
ciencies." 

Obviously,  the  principle  of  function  allocation  as  it  has  been  de¬ 
ployed  so  far  can  lead  to  problems.  This  is  especially  true  for  automated 
functions  that  are  not  thoroughly  scrutinized  in  terms  of  their  impact 
on  overall  mission  performance.  There  is  a  steadily  increasing  number 
of  permanently  activated  machine  functions  of  which  the  pilot  must 
keep  track.  At  the  same  time,  there  are  more  and  more  deployable  ma¬ 
chine  functions  that  can  be  activated  at  the  option  of  the  crew.  The 
situation  can  become  very  complex  to  keep  under  control,  since  the 
crew  must  also  be  ready  at  any  time  to  take  over  all  parts  of  functions 
that  are  not  covered  by  any  machine.  This  raises  two  obvious  concerns 
with  regard  to  allocating  functions  to  the  machine  in  current  operational 
systems: 

•  Permanently  allocated  functions  are  often  event  driven  and  operate 
in  the  background.  Resulting  changes  in  constraints  for  maneuver¬ 
ability  and  pertinent  consequences  might  not  be  apparent  to  the 
crew  and  might  lead  to  overtaxing  of  the  crew  in  situation  assess¬ 
ment. 

•  Functions  intentionally  activated  by  the  crew  might  unexpectedly 
demand  far  too  much  attention  from  the  crew  because  of  complex 
handling. 

Consequently,  it  is  not  surprising  that  increasing  automation  with  no 
well-established  way  of  allocating  functions  to  avoid  the  pitfalls  men¬ 
tioned  above  implies  an  increased  potential  for  new  types  of  crew  over¬ 
taxing  and  the  resulting  human  failures,  that  is,  mission  hazards.  Deal¬ 
ing  in  the  most  efficient  way  with  the  limited  resources  of  human 
attention  is  paramount.  Therefore,  new  ways  of  automation  must  be 
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established  through  top-down  structuring  of  fundamental  requirements. 
On  the  basis  of  these  requirements,  machine  functions  can  be  specified 
that  truly  serve  mission  accomplishment.  To  describe  this  approach  in 
more  detail  is  the  main  purpose  of  this  paper. 

THE  FLIGHT  MANAGEMENT  SYSTEM 

In  a  US  investigation  into  aspects  of  the  interaction  between  human 
and  machine  in  the  cockpit  (Wise  et  al.,  1993),  some  of  the  problems 
with  the  night  management  system  were  highlighted.  Other  investiga¬ 
tions  eame  to  similar  conclusions. 

The  flight  management  system  receives  information  about  the  actual 
flight,  including  data  about  the  destination,  the  flight  plan  to  the  desti¬ 
nation  with  way  points  and  altitudes,  weather  information,  and  load 
weight.  When  all  this  information  is  keyed  into  the  system  by  the  crew 
(which  can  become  a  significant  interactive  effort),  the  Hight  manage¬ 
ment  program  can  be  initialized.  From  then  on,  the  aircraft  can  fly 
autonomously  unless  changes  of  inputs  have  to  be  keyed  in  because  of 
unexpected  occurrences  in  the  overall  (light  situation.  The  investigation 
concluded  that  pilots  run  into  difficulties  in  time-critical  situations  with 
unforeseen  impacts,  such  as  receiving  new  air  traffic  control  instruc¬ 
tions.  In  such  situations,  there  is  not  enough  time  to  enter  the  neces¬ 
sary  inputs  and  interpret  the  computational  results  delivered  by  the 
night  management  system.  These  arc  the  situations  in  which  the  pilots 
might  be  left  on  their  own  (Wiener,  1989;  Amalbcrti  &  Dcblon,  1992; 
Sartcr  &  Woods,  1993)  with  questions  like: 

•  What  is  it  doing? 

•  Why  did  it  do  that? 

•  What  will  it  do  next?  or 

•  How  did  it  ever  get  into  that  mode? 

Thus,  the  night  management  system  is  usually  turned  off  in  just  the 
situations  where  pilots  arc  looking  hungrily  for  assistance  (Heldt, 
1993).  These  obvious  deficiencies  clearly  indicate  that  the  goal  of 
automating  the  cockpit  to  increase  (light  safety  has  fallen  somewhat  out 
of  sight.  Therefore,  it  is  time  now  to  reconsider  the  basic  requirements 
for  machine  support  in  the  cockpit,  especially  with  regard  to  situation 
assessment  tasks  of  the  crew,  including  sensory  and  information- 
processing  functions. 
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BASIC  REQUIREMENTS  FOR  COCKPIT  AUTOMATION 

There  are  a  great  number  of  well -formulated  requirements  at  hand  for 
human-machine  interaction  in  the  cockpit,  including  those  for  “human- 
centered  automation”  (Billings,  1991).  To  guide  future  automation  so  it 
meets  the  aims  of  human-centered  automation,  however,  one  must  be 
able  to  assess  how  much  certain  individual  requirements  from  the  long 
list  of  existing  ones  contribute  to  the  design  goals,  particularly  when 
trade-offs  become  necessary.  Therefore,  a  top-down  structure  comprising 
the  minimum  set  of  basic  requirements  is  needed  to  ease  the  engineering 
task  of  converting  these  requirements  into  a  technical  product.  Such  a 
structure  will  be  described  in  what  follows. 

To  resolve  this  problem,  we  ask,  first,  what  is  to  be  achieved  by 
automation?  What  is  the  objective  of  automating  pilot  functions?  This 
can  be  answered  very  quickly  by  the  following  general  statement:  Over¬ 
taxing  of  the  cockpit  crew,  as  defined  earlier,  is  to  be  avoided.  This 
means  that  the  demands  on  the  cockpit  crew  must  be  kept  at  a  normal 
level  for  all  situations  and  situation-dependent  tasks,  subject  to  certain 
task  categories  in  the  domains  of  flight  control,  navigation,  communi¬ 
cation,  and  system  handling,  such  as: 

•  situation  assessment; 

•  planning  and  decision  making; 

•  plan  execution. 

For  these  task  categories,  the  following  priority  list  of  basic  require¬ 
ments,  organized  as  a  two-level  hierarchy,  can  be  established  (Onken, 
1993).  These  requirements  are  essentially  equivalent  to  the  requirements 
for  human-centered  automation  as  stated  in  Billings  (1991),  except  that 
they  arc  structured  from  an  engineering  perspective.  They  can  be  formu¬ 
lated  as  follows: 

•  To  avoid  overtaxing  the  crew  in  situation  assessment,  the  top  re¬ 
quirement,  Basic  Requirement  7,  should  be  met,  that  is: 

In  the  presentation  of  the  full  picture  of  the  flight  situation,  it 
must  be  ensured  that  the  attention  of  the  cockpit  crew  is  guided 
toward  the  objectively  most  urgent  task  or  subtask  of  that 
situation. 
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•  To  avoid  or  decrease  overtaxing  of  the  crew  in  planning  and  deci¬ 
sion  making  as  well  as  plan  execution,  as  a  subordinate  require¬ 
ment,  Basic  Requirement  2  can  be  formulated: 

If  basic  requirement  1  is  met,  and  if  overtaxing  of  the  cockpit  crew 
(in  planning  or  plan  execution)  still  occurs,  then  this  situation 
must  be  transformed,  by  the  use  of  technical  aids,  into  a  situation 
that  can  be  handled  by  the  crew  in  a  normal  manner. 

This  particular  top-down  formulation  of  requirements  for  human- 
centered  automation  distinctly  makes  clear  that,  whatever  the  technical 
specifications  for  a  cockpit  crew  support  system,  they  are  questionable 
if  the  specification  for  the  situation  assessment  capability  of  the  sup¬ 
port  system  (basic  requirement  1),  including  the  assessment  of  the 
crew's  situation,  is  too  neglectful  and  sloppy.  How  can  the  support 
system  work  to  direct  the  crew’s  attention  if  it  cannot  assess  the  global 
situation  on  its  own?  If  the  system  is  unable  to  understand  the  unda*ly- 
ing  situation,  it  might  work  from  the  wrong  assumptions!  Thus,  if  the 
specification  fails  to  fulfil  basic  requirement  1,  this  failure  cannot  be 
compensated  by  any  automated  support  designed  to  comply  only  with 
requirement  2. 

Unfortunately,  inadequacy  caused  by  disregarding  basic  requirement  1 
was  commonly  the  case  in  the  past,  because  technical  means  were  not 
available  for  comprehensive  situation  assessment  by  the  machine.  Pre¬ 
vention  of  crew  overtaxing  in  situation  assessment  was  not  worked  into 
the  specification  in  the  systematic  manner  suggested  by  basic  require¬ 
ment  1 . 

Basic  requirement  1,  in  fact,  necessarily  leads  to  the  full  set  of  speci¬ 
fications,  which  in  turn  can  be  used  to  verify  human-centered  automa¬ 
tion  design. 

APPLICATION  OF  THE  BASIC  REQUIREMENTS 
IN  SYSTEM  DEVELOPMENT 

Obviously,  according  to  basic  requirement  1,  the  main  issue  is  to 
carefully  specify  the  situation  assessment  portion  of  the  machine  func¬ 
tions.  The  picture  of  the  flight  situation  generated  by  the  machine 
should  cover  all  aspects  of  the  situation  that  also  need  to  be  considered 
by  the  cockpit  crew.  Moreover,  it  would  be  most  desirable  if  the  ma¬ 
chine  picture  were  to  be  even  more  comprehensive  and  more  accurate. 
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This  is  already  feasible  today  for  certain  aspects.  In  principle,  therefore, 
compliance  with  basic  requirement  1  can  be  accomplished  with  the 
technology  at  hand. 

In  essence,  the  capability  of  situation  assessment  is  to  be  incorporated 
into  the  machine  part  of  the  human-machine  system  by  assigning  the 
corresponding  functions  in  parallel  to  the  machine  as  well  as  to  the 
cockpit  crew  (Figure  10.2).  In  addition,  the  machine  part  is  monitoring 
the  cockpit  crew,  and  thus  has  the  full  picture,  including  the  crew  situa¬ 
tion.  This  is  the  basis  for  cooperative  automation  so  that  the  attention 
of  the  cockpit  crew  can  be  guided  toward  the  objectively  most  urgent 
task  or  subtask  of  the  actual  situation. 

It  becomes  evident  at  this  point  that,  instead  of  allocating  functions 
either  to  the  machine  or  to  the  crew  once  and  for  all,  all  functions  nec¬ 
essary  to  fly  the  aircraft  are  not  only  inherent  crew  functions  but  also 
functions  the  machine  should  be  able  to  perform.  All  of  them  are  opera¬ 
tive  in  parallel  unless  effector  actions  are  to  be  executed.  Thus,  there  is 
no  conflict  with  the  principle  that  it  is  generally  up  to  the  crew  to  make 
the  final  decision  about  whether  to  accept  an  action  recommended  by  the 
machine  or  to  follow  their  own  ideas.  We  call  this  situation-dependent 
function  sharing  of  human  and  machine  as  partners. 

Partnership  means  that  the  capabilities  of  the  partners  are  similar,  but 
not  necessarily  identical.  Partnership  demands  effective  dialogue.  Ac¬ 
cording  to  basic  requirement  1 ,  the  presentation  of  the  full  picture  of  the 
situation  must  be  shaped  in  such  a  way  that  the  crew’s  attention  is 
guided  by  the  presentation  only  if  necessary.  In  addition,  the  crew 
should  be  able  to  talk  to  the  machine  partner  Just  as  the  crew  members 
communicate  with  each  other.  Therefore,  in  summary,  the  key  sp)ecifi- 
cations  for  the  development  of  new  generations  of  cockpit  automation 
concern  both: 

•  comprehensive  machine  knowledge  of  the  actual  flight  situation; 
and 

•  efficient  communication  between  crew  and  machine,  based  on  situa¬ 
tion  knowledge  and  new  dialogue  technology. 

How  can  the  machine’s  knowledge  about  the  actual  flight  situation  be 
established  in  order  to  meet  these  specifications?  Both  advanced  tech¬ 
niques  for  structured  knowledge  representation  and  information  process¬ 
ing  based  on  advanced  sensor  technology  (e.g.,  voice  recognition  and 
computer  vision)  make  it  possible  to  generate  a  knowledge  base  that 
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Figure  10.2.  Flight  guidance  and  control  in  the  future. 
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includes  nearly  all  static  and  dynamic  situation  elements  the  cockpit 
crew  may  be  aware  of  and  possibly  even  more  than  that.  Of  concern 
here  are  the  task-related  situation  elements  as  well  as  the  elements 
pertinent  to  the  main  players,  such  as  the  world  surrounding  the  aircraft, 
the  aircraft  itself,  and,  probably  most  important,  the  cockpit  crew. 

Knowledge  about  the  cockpit  crew  is  crucial.  Objective  knowledge 
about  the  crew  can  be  of  paramount  value.  On  the  one  hand,  the  ma¬ 
chine  might  have  a  better  picture  of  the  pilot's  status  than  the  pilot 
does,  especially  in  situations  of  imminent  overtaxing.  On  the  other 
hand,  machine  knowledge  about  the  crew  is  the  basis  for  crew-adapted 
assistance.  The  machine  cannot  assist  in  an  efficient  way  if  it  does  not 
sufficiently  understand  the  activities  and  corresponding  needs  of  the 
cockpit  crew.  In  its  most  advanced  elaboration,  knowledge  about  the 
cockpit  crew  comprises  models  of  physical  and  mental  resources  as  well 
as  behavioral  models  (see  Figure  10.3).  Therefore,  crew  behavior  for 
situation  assessment,  planning,  and  plan  execution  is  to  be  modelled  for 
normative  behavior  as  well  as  individual  behavior.  Knowledge  about  the 
crew  member’s  individual  behavior  has  to  be  learned  on  line  by  the 


Figure  10.3.  Model  of  the  cockpit  crew. 
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machine.  The  modelling  of  error  behavior  is  another  important  behav¬ 
ioral  aspect  to  be  covered.  Crew  action  modelling  should  not  be  con¬ 
fined  to  activities  with  hands  and  feet;  eye  and  head  motion,  as  well  as 
voiee  aetivity,  also  eontain  important  information  and  have  implica¬ 
tions  for  efficient  communication  management  between  machine  and 
crew. 

In  summary,  the  previous  two  sections  have  outlined  in  very  general 
terms  the  main  guidelines  that  should  be  followed  as  closely  as  possible 
to  achieve  truly  human-centered  automation.  These  guidelines  ean  easily 
be  formulated  as  system  design  specifications.  There  are  already  exam¬ 
ples  of  sueeessful  development  programs,  such  as  those  described  in 
Strohal  and  Onken  (1994),  which  have  proven  that  translating  the  basic 
requirements  into  system  concepts  and  implementation  can  be  accom¬ 
plished  successfully  in  the  way  described  here. 

THE  COCKPIT  ASSISTANT  SYSTEM  (CASSY) 

The  following  description  of  the  C(x:kpit  Assistant  System,  CASSY 
(Gerlach  &  Onken,  1994),  is  presented  as  an  example  of  how  to  design 
a  system  to  comply  with  the  ideas  discussed  above.  CASSY  was  devel¬ 
oped  at  the  University  of  the  German  Anned  Forees  in  Munich 
(Universitat  der  Bundeswehr  Miinchen)  in  ccK)pcration  with  DASA- 
Dornicr. 

The  previous  sections  pointed  out  the  importance  of  electronic  situa¬ 
tion  understanding  for  successful  machine  support.  A  system  can  under¬ 
stand  a  situation  only  if  it  has  the  appropriate  knowledge  of  the  prob¬ 
lem  spaee  in  which  it  works.  Since  CASSY  is  limited  to  civil  aviation, 
its  knowledge  base  comprises  the  elements  of  Figure  10.4. 

This  knowledge  base  is  characterized  by  static  knowledge,  for  ex¬ 
ample,  a  normative  model  of  cockpit  crew  behavior  or  knowledge  of  the 
aircraft  used,  and  dynamic  knowledge,  such  as  changing  circumstances 
during  fiight  caused  by  instructions  from  air  traffic  control  (ATC)  or 
environmental  intluenccs.  Stored  in  a  central  situation  representation, 
this  knowledge  serves  as  a  global  picture  of  the  current  situation. 

In  order  to  gather  dynamic  knowledge  and  to  transmit  its  conclusions, 
the  cockpit  assistant  system  is  placed  in  the  flight  deck.  CASSY  has 
interfaces  to  the  flight  crew,  to  the  aircraft,  and  to  ATC.  The  interfaces 
ensure  that  all  knowledge  sources  are  available  for  the  task-specific 
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modules  of  the  system.  A  diagram  of  CASSY  is  shown  in  Figure  10.5. 

The  Automatic  Flight  Planning  module  generates  a  complete  global 
flight  plan  (Prevot  &  Onken,  1993).  On  the  basis  of  its  knowledge  of 
mission  goal,  ATC  instructions,  aircraft  systems  status,  and  environ¬ 
mental  data,  an  optimized  3D/4D  trajectory  flight  plan  is  calculated. 
The  flight  plan  (or  several  plans)  is  presented  as  a  recommendation  that 
the  crew  accepts  or  modifies.  Once  a  flight  plan  is  chosen,  it  serves  as  a 
knowledge  source  for  other  CASSY  modules.  The  Automatic  Flight 
Planning  module  recognizes  conflicts  that  may  occur  during  the  flight, 
for  example,  due  to  changing  environmental  conditions  or  system  fail¬ 
ure,  and  appropriate  replanning  is  initiated.  If  necessary,  this  replanning 
process  includes  the  evaluation  and  selection  of  alternate  airports.  Since 
the  module  has  access  to  ATC  instructions,  radar  vectors  are  incorpo¬ 
rated  into  the  flight  plan  autonomously  and  the  system  estimates  the 
probable  flight  path  ahead. 

The  presentation  of  the  resulting  situation-dependent  flight  plan  to  the 
crew  directly  serves  basic  requirement  1  discussed  above  and  provides 


Crew  Mission 

intent  hypotheses  goals 

standard  behavior  constraints 

individual  behavior 
resources 


Environment 
navigation  data 
weather 
traffic 


Air  Traffic  Control 

clearances 

instructions 

information 


Aircraft 

motion  equations 
performance  data 
system  status 
sensors,  avionics 


Figure  10.4.  Knowledge  base  of  the  Cockpit  Assistant  System 
(CASSY). 
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Figure  10.5.  The  Cockpit  Assistant  System  (CASSY). 
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evidence  for  necessary  flight  plan  changes.  The  extensive  aid  in  decision 
making  and  time-eonsuming  flight  plan  calculations  supports  hasie 
requirement  2. 

The  Piloting  Expert  module  uses  the  valid  flight  plan  to  generate 
necessary  erew  actions.  It  is  responsible  for  processing  erew  models  of 
normative  and  individual  erew  behavior  (Ruekdesehel  &  Onken,  1994). 
The  normative  model  describes  prescribed  pilot  behavior  as  published  in 
pilot  handbooks  and  air  traffic  regulations.  The  model  refers  to  flight 
guidance  procedures  concerning  altitude,  speed,  course  and  heading,  as 
well  as  to  aircraft  systems  management.  Given  the  flight  plan  and  a 
pointer  on  the  current  leg,  provided  by  the  Flight  Status  Monitor,  the 
system  determines  the  appropriate  normative  values  and  tolerances  on 
aircraft  systems  and  flight  status  data.  These  data  are  adjusted  by  the 
system  to  individual  preferences  using  the  individual  erew  behavior 
model,  determined  from  an  adaptive  component. 

The  erew  model  used  to  generate  necessary  and  expected  erew  actions 
is  absolutely  vital  to  meeting  requirement  1.  It  enables  the  system  to 
identify  the  most  important  actions  on  the  basis  of  the  underlying  situa¬ 
tion  and  to  interpret  the  observed  crew  behavior. 

Expected  erew  actions  are  compared  with  the  actual  behavior  of  the 
erew  in  the  Pilot  Intent  and  Error  Recognition  module  (Witlig  & 
Onken,  1992).  Crew  actions  are  derived  indirectly  by  interpreting  the 
aircraft  data.  If  given  tolerances  are  violated,  the  erew  will  be  informed 
by  hints  and  warnings,  and  the  detected  mistake  is  pointed  out  to  the 
pilots.  When  the  erew  deviates  intentionally  from  the  flight  plan,  the 
module  cheeks  to  see  if  this  fits  one  of  a  given  set  of  hypotheses  for 
allowable  intents  that  are  also  part  of  the  erew  model.  These  hypotheses 
represent  behavior  patterns  of  pilots  in  speeifie  eases;  for  example, 
tasks  to  be  done  when  commencing  a  missed  approach  procedure  or 
when  deviating  from  the  flight  plan  to  avoid  a  thunderstorm  ahead. 
When  an  intentional  flight  plan  deviation  and  the  respective  hypothesis 
is  recognized,  appropriate  support  (e.g.,  replanning)  is  initiated. 

The  monitoring  of  the  pilots'  actions  and  the  distinction  between  error 
and  intentional  behavior  in  extraordinary  situations  serves  both  basic 
requirements  1  and  2.  Additional  monitoring  modules  arc  needed  to  en¬ 
able  the  system  to  recognize  and  interpret  current  situations.  The  Flight 
Status  Monitor  pro\\dcs  the  present  flight  state  and  progress.  It  is  also 
able  to  report  the  achievement  of  suhgoals  of  the  flight. 
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The  Environment  Monitor  gathers  information  on  the  surrounding 
traffic  (e.g.,  from  the  traffic  collision  avoidance  system)  and  weather 
conditions,  and  incorporates  a  detailed  navigational  database  of  the  sur¬ 
rounding  area.  The  operational  status  of  aircraft  systems  is  monitored 
by  the  Systems  Monitor  like  a  diagnosis  system. 

Obviously,  the  monitoring  systems  arc  essential  to  meet  the  first 
requirement,  since  their  outputs  are  an  important  part  of  the  full  picture 
of  the  present  situation.  Because  their  output  is  also  ased  to  adjust  the 
flight  plan  to  the  situation,  they  contribute  to  meeting  the  second  re¬ 
quirement  as  well.  In  addition,  the  continuous  observation  of  flight 
progress,  environment,  and  aircraft  systems  supports  the  crew  in  tedious 
or  horing  but  necessary  tasks. 

Communication  plays  an  important  role  in  CASSY.  The  kind  of 
infonnation  to  he  transmitted  in  either  direction  varies  for  the  different 
modules  (Figure  10.6).  The  information  flow  from  CASSY  to  the  crew 
and  vice  versa  is  controlled  by  the  Dialogue  Manager  module  (Gcrlach 
&  Onken,  1993).  The  many  different  kinds  of  messages  require  prcKcss- 
ing  so  that  the  appropriate  display  device  is  used  and  the  message  is 
presented  at  the  right  time.  Both  a  graphic/alphanumeric  color  display 
and  a  speech  synthesizer  arc  used  as  output  devices.  Short  warnings  and 
hints  arc  used  to  make  the  crew  aware  of  a  necessary  and  expected  action 
and  iue  transmitted  verbally  using  the  speech  synthesizer.  A  static  al¬ 
phanumeric  line  is  also  added  to  the  graphic  display  to  facilitate  percep¬ 
tion  of  difficult  verbal  messages.  More  complex  information,  for  exam¬ 
ple,  the  valid  flight  plan,  is  depicted  on  a  moving  map  on  the  graphic 
display. 

Another  important  feature  of  the  Dialogue  Manager  is  that,  since  the 
tolerances  and  danger  boundaries  are  given  in  the  crew  model  and  the 
necessary  actions  arc  inferred,  a  priority  ranking  of  the  output  message 
is  evaluated  and  the  most  important  message  is  issued  with  priority. 

The  input  information  flow  is  established  using  speech  recognition  in 
addition  to  conventional  input  mechanisms.  In  order  to  improve  speech 
recognition  pcrfonnancc,  almost  the  complete  knowledge  base  of 
CASSY  is  u.sed  to  provide  situation-dependent  syntaxes.  Thus,  the 
complexity  of  the  overall  language  model  is  reduced  significantly.  Not 
only  the  pilot's  inputs  but  also  the  inputs  from  ATC  must  he  consid¬ 
ered.  The  ATC  datalink,  indicated  in  Figure  10.6,  is  not  yet  available. 
Discrimination  of  ATC  instructions  from  pilot  input  is  achieved  hy 
picking  up  the  pilot's  verbal  acknowledgment  of  the  ATC  controller's 
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Figure  10.6.  Information  flow  in  CASSY. 
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instructions.  The  use  of  speech  input  and  output  devices  also  reflects 
the  idea  of  a  cooperative  human-electronic  crew  and  cooperation  between 
partners. 

In  Figures  10.5  and  10.6,  an  additional  module  is  shown  called  Exe¬ 
cution  Aid.  This  module  implements  several  functions  that  can  be 
called  up  by  the  crew.  Aircraft  settings,  navigational  calculations,  and 
database  inquiries  are  carried  out.  These  functions  are  similar  to  auto¬ 
mated  functions  available  in  today’s  aircraft  and  are  designed  mainly  to 
meet  requirement  2.  For  the  pilots,  the  main  difference  is  the  support  of 
speech  input,  which  facilitates  the  use  of  these  services. 

RESULTS  OF  THE  FLIGHT  TESTS 

In  June  1994,  GASSY  was  given  11  hours  of  flight  test  trials  in 
Braunschweig,  Germany. 

The  modules  of  GASSY  have  been  implemented  on  an  off-the-shelf 
Silicon  Graphics  Indigo  workstation  using  the  G  programming  lan¬ 
guage.  A  Marconi  MRS  PG  card  was  used  as  a  speaker-dependent,  con¬ 
tinuous  speech  recognition  system.  A  DEGTalk  speech  synthesizer 
served  as  speech  output  device.  Three  different  voices  were  used  to  en¬ 
able  the  pilot  to  discriminate  among  the  various  messages.  The  compo¬ 
nents  were  connected  using  serial  lines  and  Ethernet. 

The  system  was  integrated  into  the  test  aircraft  ATTAS  (Advanced 
Technologies  and  Testing  Aircraft)  of  the  German  Research  Institute  for 
Aeronautics  and  Astronautics  (Deutsche  Forschungsanstalt  fiir  Luft-  und 
Raumfahrt)  in  Braunschweig.  The  aircraft  is  well  equipped  for  flight 
guidance  experiments,  since  it  can  be  operated  via  a  single-seat,  experi¬ 
mental  cockpit  located  in  the  cabin.  An  Ethernet  connection  to  the 
GASSY  workstation  was  used  to  simulate  an  avionic  bus  system  for 
the  aircraft  interface  in  either  direction.  For  the  ATG  interface,  two  ap¬ 
proaches  were  tested:  a  simulated  ATG  datalink  and  the  pilot's  acknowl¬ 
edgment  of  ATG  instructions. 

The  test  flights  comprised  instrument  flights  from  the  regional  airport 
of  Braunschweig  to  the  international  airports  of  Frankfurt,  Hamburg, 
and  Hannover,  at  which  a  missed  approach  procedure  was  conducted 
before  returning  to  Braunschweig. 

The  experiments  proved  GASSY's  functions  throughout  the  complete 
flight  from  takeoff  to  landing.  Speech  recognition  performed  well  in  the 
aircraft,  since  the  surrounding  noise  was  primarily  engine  noise,  which 
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did  not  change  much  during  flight.  The  recognition  rates  were  similar  to 
those  achieved  in  the  quieter  simulator  environment  at  the  university  in 
Munich  where  CASSY  was  developed  and  tested  earlier. 

One  important  aspect  of  the  tests  was  to  prove  the  system  in  the 
high-density  ATC  of  German  airports,  which  could  not  be  tested  in 
simulator  test  runs.  During  the  trials,  any  given  ATC  instruction  could 
be  processed  and  integrated  into  the  flight  plan  by  CASSY.  Compared 
to  available  flight  management  systems,  the  autonomous  integration  of 
ATC  radar  vectors  proved  to  be  faster  and  did  not  lead  to  distracting  in¬ 
formation  input. 

On  the  basis  of  the  flight  plan,  the  correct  expected  pilot  actions  were 
generated  and  pilot  errors,  provoked  or  nonprovoked,  were  detected  and 
the  appropriate  warnings  issued.  Wrong  warnings  occurred  infrequently 
and  were  noncritical  in  any  case. 

Two  pilots  flew  with  CASSY  in  the  test  aircraft.  Additional  pilots 
from  Lufthansa  German  Airlines  panicipated  to  observe  the  tests  and  to 
serve  as  a  second  pilot  beside  the  test  pilot, 

CASSY  was  well  accepted  by  the  pilots  throughout  the  trials.  In  par¬ 
ticular,  the  pilots  appreciated  the  autonomous  flight  plan  functions  of 
CASSY.  Warnings  and  hints  were  considered  justified,  and  corrective 
system  inputs  were  made.  Speech  input  was  generally  used  when  com¬ 
plex  inputs  were  required,  for  example,  to  enter  frequency  settings  using 
the  simple  name  of  the  station  instead  of  its  more  difficult  frequency. 

CONCLUSIONS 

The  time  has  come  when  future  cockpit  systems  no  longer  will  be 
designed  on  the  basis  of  vague  specifications.  Advances  in  technology 
make  it  possible  systematically  to  translate  the  requirements  for  human- 
centered  automation  into  clear-cut  specifications  for  cockpit  systems. 

Machine  functions  will  be  incorporated  that  provide  more  than  just 
support  for  planning  and  plan  execution,  as  emphasized  in  the  past. 
Instead,  the  main  emphasis  will  be  on  autonomous  machine  situation 
assessment  in  parallel  with  the  crew’s  situation  assessment  activity. 
This  will  lead  to  better  machine  understanding  of  the  crew’s  real  needs 
and,  consequently,  to  more  efficient  support  to  ensure  flight  safety  and 
mission  effectiveness. 

The  Cockpit  Assistant  System  (CASSY)  is  an  example  of  how  a 
pilot  support  system  might  look  to  achieve  human-centered  automa- 
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lion.  It  is  designed  to  meet  the  basic  requirements  for  cockpit  systems 
as  stated  in  this  paper.  The  successful  flight  test  trials  with  this  system 
show  that  a  new  generation  of  cockpit  automation  systems  can  be  in¬ 
troduced  for  higher  standards  in  flight  safety  and  mission  effectiveness. 
There  are  already  examples  of  successful  development  programs,  which 
have  proven  that  the  method  of  implementing  design  guidelines  de¬ 
scribed  in  this  paper  leads  systematically  to  the  desired  system  perform¬ 
ance. 
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REVERSE  ENGINEERING  ALLOCATION 
OF  FUNCTION  METHODOLOGY 
FOR  REDUCED  MANNING  (REARM) 

T.  B.  Malone 


As  the  avaiiabihty  of  manpower  for  military  systems,  as  well 
as  budgets  to  support  fielded  systems,  are  reduced,  more  at¬ 
tention  is  being  given  to  the  need  to  reduce  personnel  levels 
in  future  systems  compared  with  the  level  in  e.xi sting  systems. 
The  major  approach  to  reducing  manning  is  to  reallocate 
functions  to  automated  performance  that  were  previously 
conducted  manually,  thereby  decreasing  the  workload  on 
human  operators  and  reducing  the  number  of  personnel  re¬ 
quired.  In  this  strategy,  the  emphasis  is  on  a  redetermination 
of  the  role  of  the  human  in  the  system.  An  approach  for  deter¬ 
mining  the  role  of  the  human  conducted  for  the  purpose  of  re¬ 
ducing  system  manning  below  that  required  in  the  existing 
system  is  designated  ” REARM”  (for  Reverse  Engineering  Al¬ 
location  of  function  methodology  for  Reduced  Manning). 
REARM  incorporates  several  of  the  tools  available  in  the 
Carlow  International  HSI  IDEA  (human-system  integration  In¬ 
tegrated  Decision/Engineering  Aid)  system. 


BACKGROUND 

The  Navy  combatant  ship  constitutes  one  of  the  most  complex  weapon 
systems  in  a  country's  dcrense  arsenal.  It  is  a  multipersonnel  system 
conducting  multiple  operations  (air,  shore  bombardment,  warfare  opera¬ 
tions,  search  and  rescue,  etc.)  in  multiple  warfare  environments  (antiair 
warfare  or  A  AW,  antisubmarine  warfare  or  ASW,  antisurface  warbire  or 
ASUW,  electronic  warfare  or  EW,  and  strike  warfare),  as  an  independent 
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combatant,  a  member  of  a  squadron,  or  an  element  of  a  battle  force.  The 
ship  systems  employed  in  the  fleet  today,  and  those  being  designed  for 
the  fleet  tomorrow,  make  severe  demands  on  the  readiness,  performance 
effectiveness,  and  physical  capabilities  of  the  personnel  who  must  oper¬ 
ate  and  maintain  them.  These  systems  are  complex,  highly  sophisti¬ 
cated,  and  extremely  demanding  of  the  sensory,  motor,  and  cognitive 
skills  and  decision-making  capabilities  of  system  personnel. 

The  operational  environment  of  the  next  generation  of  combatant 
ships  will  impose  extreme  information  loads  on  the  humans  responsi¬ 
ble  for  managing,  operating,  maintaining,  and  supporting  shipboard 
systems.  The  variety  and  interactive  complexity  of  systems,  equipment, 
and  personnel  in  the  ship  environment,  coupled  with  requirements  for 
rapid  planning,  scheduling,  and  deployment  of  mission  elements  within 
a  dynamic,  unpredictable  threat  environment,  will  converge  to  impose 
an  untenable  workload  on  the  human  operator.  Cognitive  workload  will 
continue  to  be  particularly  high  for  ship  personnel  due  to  a  variety  of 
interdependent  elements,  including  increases  in  the  number  and  rate  of 
decisions,  as  well  as  increases  in  the  complexity  and  quantity  of  data 
that  must  be  processed  in  order  to  make  those  decisions.  Traditionally, 
such  increases  in  workload  have  been  compensated  for  by  eommensurate 
increases  in  the  number  of  personnel;  however,  current  and  projected 
budgetary  constraints,  coupled  with  demographic  data  projecting  a  con¬ 
tinuing  reduction  of  military-aged  males  over  the  next  twenty  years, 
reduce  the  feasibility  of  this  solution.  The  requirement  to  reduce  man¬ 
ning  levels  as  compared  with  preceding  systems  is  becoming  a  fact  of 
life  for  military  systems  in  general.  Projected  defense  department  budg¬ 
ets  demonstrate  a  definite  trend  toward  reducing  the  numbers  of  person¬ 
nel  available  to  operate  emerging  military  systems. 

In  addressing  the  issue  of  performing  system  funetions  with  fewer 
human  operators  and  maintainers  as  compared  with  existing  systems, 
the  function  allocation  strategy  is  not  simply  to  assign  funetions  to 
automated  or  manual  performance  on  the  basis  of  the  different  capabili¬ 
ties  and  capacities  of  the  two,  as  exemplified  in  the  Fitts'  List  approach. 
Rather,  the  strategy  is  to  automate  funetions  to  the  extent  necessary  to 
enable  the  required  reduction  in  personnel,  with  attendant  provisions  for 
decision  aiding,  task  simplification,  and  design  in  conformity  with  hu¬ 
man  factors  engineering  standards  to  ensure  adequate  levels  of  human 
performance. 
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In  dealing  with  human-computer  systems,  it  is  also  important  to 
realize  that  the  issue  is  not  so  much  defining  the  allocation  of  system 
functions  or  tasks  to  human  or  machine  performance  as  it  is  cstahlish- 
iiig  the  role  of  the  human  in  the  system.  In  a  human-machine  system 
where  both  components  arc  equally  competent  to  perform  individual 
functions  and  tasks,  the  design  issue  is  to  determine  the  role  of  the  hu¬ 
man  vs.  automation  in  the  performance  of  each  function  or  task.  The 
emphasis  on  the  role  of  the  human  in  the  system  acknowledges  the  fact 
that  the  human  has  some  role  in  every  system  function  or  task.  In  some 
eases,  that  role  may  encompass  actual  performance  of  the  function  or 
task. 

It  is  also  important  to  realize  that  an  assigned  role  for  human  per- 
fonnance  may  change  with  changes  in  operational  conditions.  Thus,  a 
task  performed  optimally  hy  a  human  under  certain  conditions  of  work¬ 
load,  time  constraints,  or  task  priority  may  be  performed  more  opti¬ 
mally  by  machine  under  other  conditions.  It  is  also  important  to  keep 
in  mind  that  automating  a  function  or  task  docs  not  logically  mean  that 
the  human  docs  not  have  a  role,  that  he  or  she  has  effectively  been  de¬ 
signed  out  of  the  system  for  that  specific  function  or  task.  Rather,  in  an 
automated  function  or  task,  the  role  of  the  human  is  that  of  a  manager, 
monitor,  decision  maker,  system  integrator,  or  backup  performer. 

Historically,  the  most  frequently  applied  method  to  reduce  manning 
levels  has  been  to  automate  operator  tasks,  thereby  reducing  operator 
workload  and  manning  requirements.  Human-systems  integration  (HSI) 
generally  attempts  to  reduce  manning  levels  by  automating  specific 
tasks  and  establishing  the  potential  for  reallocating  human  tasks  to 
automation,  or  redistributing  human  tasks  to  other  humans.  High-driver 
tasks  arc  investigated  to  determine  the  potential  for  reallocating  the  task 
or  task  sequence  to  automated  pcrfomiancc  or  to  another  operator. 
Analyses  arc  conducted  to  assess  the  effect  of  rcalkx:ation  of  tasks  on 
individual  operator  workload  and  on  the  potential  for  manning  reduc¬ 
tion.  Techniques  to  reduce  manning  levels  through  training  have  also 
focused  on  redistribution  of  tasks  among  crew  mem  hers.  High-driver 
tasks  are  examined  to  determine  the  potential  for  cross  training  and  or¬ 
ganic,  on-hoard  training. 

Attempts  to  reduce  manning  levels  through  consolidation  of  operat¬ 
ing  positions  have  been  only  marginally  succcsslul.  This  lack  of  suc¬ 
cess  has  resulted  from  two  main  obstacles:  (1)  specialized  skills  and 
knowledge  required  for  different  operating  positions  preclude  simple 
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cross  training;  and  (2)  task  performance  for  existing  positions  may  in¬ 
volve  critical  activities  that  are  parallel  in  time.  Recent  advances  in  the 
fields  of  artificial  intelligence  and  HSI  afford  the  capability  to  overcome 
these  obstacles  by  providing  on-line  decision  aiding,  by  enhancing  cross 
training  through  organic  training,  and  by  allowing  some  measure  of 
operators'  specialized  skills  and  knowledge  to  reside  in  the  computer. 
This  approach,  which  involves  what  are  typically  termed  “expert  sys¬ 
tems,”  has  met  with  considerable  success  in  both  commercial  and  gov¬ 
ernment  applications. 

The  underlying  rationale  of  the  HSI  strategy  for  manning  reduction 
involves  the  application  of  HSI  techniques  to  reduce  the  physical  and 
cognitive  workloads  imposed  on  ship  personnel,  permitting  redistribu¬ 
tion  of  workload  among  automation  and  human  performance  and  among 
crew  members,  consolidation  of  existing  operating  positions,  simplifi¬ 
cation  of  operator  tasks,  and  reduction  of  overall  manning  levels.  Ap¬ 
plication  of  HSI  technology  to  reduce  manning  has  been  addressed  for¬ 
mally  only  in  recent  years.  The  potential  for  reducing  manning  through 
improved  task  simplification  and  improved  human-machine  interface 
design  has  been  demonstrated  in  a  number  of  studies. 

The  critical  issue  in  the  HSI  reduction  of  manning,  then,  is  the  rela¬ 
tionship  between  manning  and  workload.  The  basis  for  predicting  man¬ 
ning  requirements  must  be  the  workload  associated  with  the  roles  of 
humans  in  system  operations.  The  problem,  for  the  HSI  specialist,  lies 
in  the  measurement  of  workload.  Workload  measures  and  methods  being 
sought  involve  human  sensory,  psychomotor,  and  cognitive  capacities 
and  the  demands  placed  on  these  by  operator  tasks  inherent  in  the  design 
of  ship  systems.  While  workload  measures  in  the  area  of  physical  work, 
muscular  exertion,  and  physical  fatigue  are  definitely  of  interest,  the 
greatest  uncertainty  lies  in  defining  workload  in  tasks  that  do  not  require 
much  physical  effort  but,  rather,  load  the  operator  in  terms  of  percep¬ 
tual,  cognitive,  and  decision-making  skills. 

An  obvious  difficulty  in  measuring  these  capabilities  and  the  demands 
created  by  system  tasks  is  that  the  capabilities  and  the  inferred  workload 
are  not  observable.  What  is  observable,  however,  and  what  ultimately 
contributes  to  or  degrades  total  system  performance,  is  operator  task 
performance  in  terms  of  response  speed  and  accuracy.  The  time  taken  to 
respond  to  stimulus  events  and  the  quantitative  and/or  qualitative  accu¬ 
racy  of  the  response  are  measurable,  at  least  in  principle,  and  will  influ¬ 
ence  total  system  performance. 
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Workload  (or  overload)  is  an  intervening  variable  that  must  be  in¬ 
ferred  from  observable  pcrfoimance.  It  is  presumed,  despite  the  elusive 
and  indirect  nature  of  the  workload  concept,  that  workload  docs  exist  and 
that  the  workload  level  imposed  by  a  system  task  or  sequence  of  tasks 
will  influence  task  behavior. 

REQUIREMENTS 

Functions  or  tasks  that  arc  candidates  for  automation  can  be  identified 
by  determining  the  required  role  of  the  human  in  the  system.  The  clas¬ 
sical  method  for  determining  the  role  of  the  human  in  a  complex  sys¬ 
tem  involves  allocation  of  functions  or  tasks  to  human  or  machine 
(automated)  performance.  Function/task  allocations  can  be  cither  static 
or  dynamic.  Static  allocations  identify  which  functions  or  tasks  should 
be  ali(x:atcd  to  human  pcrfoimance  vs.  machine  performance  based  on 
an  assessment  of  the  requirements  associated  with  the  function/task  and 
the  unique  capabilities  and  limitations  of  the  human  and  the  machine. 
Static  allocations  arc  usually  made  on  the  basis  of  lists  (Fitts’  lists)  that 
compare  the  relative  capabilities  and  limitations  of  human  and  machine 
performance  along  .specific  dimensions. 

Dynamic  allocations  assume  that  the  optimum  allocation  strategy  can 
change  with  operational  conditions,  workloads,  and  mission  priorities. 
According  to  Rouse  (1977),  a  dynamic  approach  allocates  a  particular 
task  to  the  decision  maker  (human  or  machine)  who  has  the  resources 
available  at  the  moment  for  pcrfomiing  the  task.  Rouse  (1981)  identi¬ 
fied  the  advantages  of  a  dynamic  approach  over  a  static  approach  as: 
improved  utilization  of  system  resources;  less  variability  of  the  hu¬ 
man's  workload;  and  provision  of  the  human  with  improved  knowledge 
of  the  overall  system.  Revesman  and  Green.stein  (1983)  recommended 
an  approach  in  which  the  human  and  the  computer  work  on  tasks  in 
parallel,  with  the  computer  .selecting  actions  so  as  to  minimize  interfer¬ 
ence  with  the  human.  Here,  the  human  is  not  forced  to  change  plannaf 
actions  and  he  or  she  retains  the  primary  role  in  the  system.  In  this 
implementation,  the  computer  must  make  predictions  about  the  hu¬ 
man's  actions  and  must,  therefore,  have  a  model  of  the  human  in  terms 
of  the  actions  the  human  will  take  at  a  given  point  and  under  certain 
circumstances.  The  computer  would  use  this  model  of  human  decision 
making  to  predict  the  human's  actions  and  to  select  other  actions  that  do 
not  replicate  or  interfere  with  the  human’s  actions. 
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According  to  Woods  (1985),  the  role  of  the  human  has  shifted  with 
increased  control  automation  and  developments  in  computational  tech¬ 
nologies.  The  shift  is  away  from  the  pcrccptual-motor  skills  needed  for 
direct  manual  control  to  cognitive  skills  of  the  type  required  to  support 
roles  such  as  monitor,  planner,  and  fault  manager.  The  key  to  effective 
application  of  computational  technology  is  to  conceive,  model,  design, 
and  evaluate  the  joint  human-machine  cognitive  system.  The  configura¬ 
tion  or  organization  of  the  human  and  machine  components  is  a  critical 
determinant  of  the  performance  of  the  system  as  a  whole.  This  means 
using  computational  technology  to  aid  the  user  in  the  process  of  reach¬ 
ing  a  decision,  not  to  make  or  recommend  solutions.  If  joint  cognitive 
system  design  is  to  be  effective,  models  and  data  are  needed  that  describe 
the  critical  factors  for  overall  system  performance  (Woods,  1985). 

METHODOLOGY 

The  major  requirement  imposed  by  the  HSI  initiative  is  that  consid¬ 
erations  for  the  human  in  the  system,  including  manning  levels,  must 
influence  system  design.  In  order  to  influence  design,  attention  to  HSI 
requirements,  again  including  manning,  must  begin  early  in  the  system 
development  process.  To  have  the  maximum  impact  on  design  deci¬ 
sions,  HSI  requirements  should  be  addressed  prior  to  milestone  0,  while 
mission  needs  are  being  determined,  manning  constraints  are  being 
specified,  and  alternate  approaches  are  being  considered.  The  most  effec¬ 
tive  method  for  addressing  HSI  issues  early  in  the  development  process 
is  to  focus  on  lessons  learned  in  baseline  comparison  systems  or  prede¬ 
cessor  systems.  Lessons  learned  include  problems  identified  in  baseline 
comparison  systems  that  should  be  avoided  in  the  emerging  system,  as 
well  as  positive  aspects  of  the  baseline  system  that  should  be  considered 
in  the  new  system.  Through  the  reengineering  process,  operations  and 
tasks  in  existing  systems  that  impose  heavy  workloads  on  humans  can 
be  identified,  and  requirements  for  alternative  allocations  can  be  speci¬ 
fied.  A  second  method  for  addressing  human  requirements  and  considera¬ 
tions  early  in  system  development  is  the  use  of  computer  simulation  to 
model  human  performance  in  system  missions  and  operations. 

The  HSI  approach  to  influencing  system  design  early  in  system  ac¬ 
quisition,  with  special  emphasis  on  reduction  of  manning  in  the  emerg¬ 
ing  system,  uses  a  four-step  process  to  address  the  issue  of  establishing 
the  optimum  role  of  the  human.  These  steps  are:  (1)  identifying  candi- 
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date  roles  of  the  human;  (2)  identifying  specific  requirements  associated 
with  these  roles  for  specific  scenarios;  (3)  modelling  expected  human 
performance  in  the  set  of  assigned  roles  for  the  scenarios;  and  (4)  assess¬ 
ing  the  alternative  concepts  of  the  role  of  the  human  in  terms  of  their 
effectiveness,  affordability,  and  risk  reduction. 

•  Identifying  candidate  roles  for  the  humans. 

In  identifying  candidate  roles  for  the  human  in  the  system,  the  em¬ 
phasis,  from  a  reduced  manning  perspective,  is  to  automate  tasks 
that  are  currently  performed  manually.  Identifying  manpower  de¬ 
termination  lessons  learned  in  baseline  comparison  systems  in¬ 
volves  assessing  the  adequacy  of  the  allocation  of  functions  to  hu¬ 
man  or  machine  performance  in  these  systems,  and  identifying 
where  human  functions  and  tasks  can  be  reallocated  to  automated 
performance.  This  assessment  requires  a  reverse  engineering  of  the 
function  allocation  approach  underlying  the  design  concept  imple¬ 
mented  in  the  baseline  or  existing  system.  Through  the  reverse  en¬ 
gineering  technique,  the  rationale  for  allocation  decisions  can  be 
made  explicit  and  opportunities  for  alternate  allocations  can  be  ex¬ 
plored.  Alternative  concepts  of  the  role  of  the  human  involve  alter¬ 
nate  approaches  to  automation,  decision  aiding  to  reduce  human 
workload,  and  improved  design  of  human-machine  interfaces  to 
simplify  tasks  and  reduce  workloads. 

•  Identifying  specific  requirements  associated  with  candidate  human 
roles. 

The  requirements  associated  with  specific  function  allocation/role- 
of-the-human  concepts  include  task  requirements  (information,  per¬ 
formance  capabilities,  decision  and  support  requirements,  task  se¬ 
quencing,  and  time  dimensions  of  tasks),  human  knowledge/skill 
requirements,  and  requirements  for  containing  human  errors.  These 
requirements  are  generated  for  specific  mission  scenarios  that  repre¬ 
sent  configurations  of  mission  objectives,  threat  and  own  force  de¬ 
ployment,  system  readiness,  and  special  conditions  (environmental, 
operational,  and  tactical). 

•  Modelling  human  performance. 

For  the  task  sequences  and  associated  requirements  defined  for  spe¬ 
cific  mission  scenarios,  human  performance  must  be  modelled  to 
identify  potential  problem  areas.  The  modelling  process  is  twofold. 
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First,  a  task  performance  model  is  developed  through  application  of 
task  analysis.  When  task  sequences  and  requirements  are  suffi¬ 
ciently  well  understood,  a  task  network  simulation  is  conducted  to 
assess  the  impact  of  the  specific  function  allocation  or  role  given 
to  the  human  on  human  performance  and  workload. 

•  Assessing  alternative  concepts  of  the  role  of  the  human. 

The  HSI  appraisal  of  function  allocation/role-of-the-human  con¬ 
cepts  will  include  an  assessment  of  technological  requirements  as¬ 
sociated  with  the  concept,  and,  for  individual  concepts,  assessment 
of  effectiveness,  affordability  and  risk.  The  technology  assessment 
will  focus  on  the  extent  to  which  technological  advancements  are 
needed  to  support  implementation  of  a  specific  concept.  The  as¬ 
sessment  of  concept  effectiveness  will  address  the  extent  to  which 
the  concept  meets  system  requirements  and  will  enhance  system 
operability,  usability,  maintainability,  support-ability,  survivabil¬ 
ity,  and  safety. 

The  assessment  of  concept  affordability  will  determine  the  extent  to 
which  life-cycle  resource  requirements  are  met  for  operational  man¬ 
power,  maintenance  personnel,  training,  personnel  nonavailability  due 
to  accident,  expected  human  error  rates,  expected  time  to  repair,  sup- 
portability,  and  expected  system  down  time.  The  assessment  of  risk  for 
alternative  function  allocation/role-of-the-human  concepts  involves  a 
determination  of  critical  factors  that  will  have  a  significant  impact  on, 
and  carry  risks  for,  readiness,  life-cycle  costs,  schedule,  performance,  or 
design.  These  include  such  items  as:  tasks,  task  sequences,  and  task 
complexity;  environments  and  environmental  controls;  equipment  de¬ 
sign  features;  maintenance  requirements;  information  requirements; 
manning  requirements  and  associated  workloads;  personnel  skill  levels 
and  training  requirements;  and  potential  existence  of  health  and  safety 
hazards. 


REARM 

A  methodology  is  needed  that  will  make  it  possible  to  assess  the 
allocation  of  function  strategy  in  an  existing  system  through  a  reverse¬ 
engineering  technique.  This  methodology  should  be  automated  as  much 
as  possible  and  should  provide  for  effective  interfacing  with  a  Simula- 
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tion  methodology  so  the  effects  of  specific  function  allocation  schemes 
on  workloads,  and,  consequently,  on  manning  levels,  can  be  determined. 

One  methodology  for  integrating  the  human  into  a  complex  system 
was  developed  by  Carlow  International  for  the  US  Army  Human  Re¬ 
search  and  Engineering  Directorate  (USAHRED),  the  Naval  Sea  Sys¬ 
tems  Command  (NAVSEA),  and  the  Space  and  Naval  Warfare  Systems 
Command  (SPA WAR).  This  approach  is  known  as  the  HSI  IDEA 
(Integrated  Decision/Engineering  Aid)  (Malone  et  al.,  1992).  A  subset 
of  the  IDEA  tools  aimed  at  determining  the  roles  of  the  human  in  a 
system  to  support  reduced  manning  has  been  designated  “REARM”  (for 
Reverse  Engineering  Allocation  of  function  methodology  for  Reduced 
Manning).  REARM  incorporates  several  of  the  tools  available  in  the 
IDEA  system,  including  the  IDEA  Lessons  Learned  Database  (IDEAL), 
the  Role-of-Man  Analysis  Tool  (ROMAN),  the  NETWORK  Tool  for 
creating  a  graphic  task  network,  the  IDEA  Task  Analysis  Tool  (I- 
TASK),  the  IDEA  Simulation  for  Workload  Assessment  and  Modelling 
Tool  (SIMWAM)  for  task  network  simulation,  and  the  IDEA  HSI  As¬ 
sessment  Tool  (ASSESS).  The  REARM  methodology  seeks  to  de¬ 
scribe,  through  reverse  engineering,  the  allocation  of  function  strategy 
evident  in  an  existing  system,  and  the  negative  and  positive  aspects  of 
the  strategy.  The  relationships  among  the  IDEA  tools  under  REARM 
are  depicted  in  Figure  11.1. 

In  the  IDEA  methodology,  the  existing  system  is  described  in  the 
Lessons  Learned  Database  (IDEAL).  The  implemented  roles  of  the  hu¬ 
man  are  developed  through  application  of  an  automated  tool  designated 
the  Role-of-Man  Analysis  Tool  (ROMAN).  The  IDEAL  provides  tech¬ 
niques  to  acquire,  analyze,  classify,  prioritize,  and  store  data  on  lessons 
learned  describing  problems  as  well  as  positive  aspects  of  the  function 
allocation  scheme  in  the  existing  system. 

ROMAN  allows  the  analyst  to  import  a  set  of  functions  or  tasks  and 
to  assign  roles  to  humans  and  automation  in  the  performance  of  each 
function  and  task.  As  each  function  or  task  is  presented  to  the  analyst,  a 
decision  must  be  made  regarding  which  component  (human  or  machine) 
should  be  the  performer  of  the  function  or  task.  When  an  assignment 
cannot  be  made  readily,  the  analyst  selects  the  tool's  consultation  fea¬ 
ture.  The  tool  then  presents  a  series  of  questions  in  which  the  analyst  is 
asked  to  scale  some  dimension  of  the  task,  operational  conditions  and 
environment,  user  capabilities,  and  mission  priorities.  Based  on  the 
analyst’s  responses,  the  tool  recommends  that  the  task  be  assigned  to 
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Figure  11.1.  Relationship  among  IDEA  tools  for  determining  function  allocation  and  the  role  of  the  human  to 
achieve  reduced  manning. 
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human  or  machine  performance.  In  each  case  where  an  assignment  of 
task  performance  has  been  made,  the  analyst  is  asked  to  identify  the  role 
of  the  human  and  the  role  of  the  machine  in  the  perfonnance  of  the 
task. 

The  assigned  roles  for  each  task  arc  then  exported  to  the  IDEA  auto¬ 
mated  Task  Analysis  tool  (I-TASK),  where  specific  requirements  for 
task  performance  arc  identified  for  each  task  under  the  specific  allocation 
strategy  and  role  assignments.  I-TASK  compri.scs  a  data  bank  of  issues 
and  concerns  for  human  perfonnance  of  system  tasks  as  affected  by  the 
selected  roles  of  the  human  and  the  machine  in  the  completion  of  the 
tasks.  For  tasks  that  are  cognitive  in  nature,  cither  because  of  the  task 
itself  or  because  of  the  assigned  role  of  the  human  in  the  perfonnance  of 
the  task,  the  task  data  are  exported  to  the  IDEA  Cognitive  Task  Analy¬ 
sis  Tool  (1-COG)  fora  refined  analysis  addressing  the  cognitive  aspects 
of  required  human  performance.  The  resulting  task  data  are  then  im¬ 
ported  back  into  the  I-TASK  Tool. 

The  results  of  the  task  analysis  are  then  exported  to  the  IDEA 
NETWORK  Tool,  which  describes  task  sequences  in  a  graphic  flow¬ 
chart  format,  with  task  descriptions  available  in  text  format.  The  task 
descriptions  maintained  in  the  NETWORK  Tool  comprise  a  subset  of 
the  requirements  derived  for  each  task  in  the  I-TASK  Tool.  These  task 
descriptions  specify  the  performer  of  the  task,  the  tasks  that  must  pre¬ 
cede  the  specific  task,  and  the  tasks  that  arc  dependent  on  the  specific 
task;  the  role  of  the  human  in  task  performance  if  the  human  is  not  the 
performer;  the  estimated  time  required  for  task  completion;  and  the 
process  variables  associated  with  performance  of  the  task.  Process  vari¬ 
ables  include  factors  that  have  a  bearing  on  task  performance  and  that 
can  vary  for  any  simulation  exercise.  Process  variables  typically  include 
capabilities  or  readiness  of  ship  systems,  opcrational/cnvironmcntal 
conditions,  mission  data,  and  threat  characteristics. 

The  NETWORK  Tool  runs  on  the  Apple  Macintosh  computer  and 
takes  advantage  of  the  Macintosh  graphics  capabilities  and  user  interface 
to  allow  the  analyst  to  draw  a  task  network.  A  set  of  drawing  tools  is 
provided  to  generate,  locate,  and  connect  task  boxes.  A  task  box  can  be 
named  and  then  opened  to  prcxlucc  a  set  of  dialogue  windows.  These 
windows  allow  the  analyst  to  input  details  of  a  given  task,  including 
such  things  as  the  opcralor(s)  qualified  to  perfonn  the  task,  the  priority 
of  the  task,  conditions  that  must  be  met  before  the  task  can  be  started. 
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and  parameters  that  specify  the  probability  distribution  of  completion 
time  for  the  task. 

Once  a  task  network  has  been  defined,  the  data  are  exported  to  the 
IDEA  simulation  tool,  SIMWAM  (Simulation  for  Workload  Assess¬ 
ment  and  Modelling)  for  simulation  of  the  task  network,  exported  to  the 
I-TASK  (task  analysis)  Tool,  or  exported  to  any  of  the  Macintosh 
graphics  applications  for  documentation  purposes. 

SIMWAM  is  a  task  network  simulation  tool  that  can  execute  a  net¬ 
work  model  previously  defined  by  NETWORK.  SIMWAM  allows  an 
interactive,  microprocessor-based  simulation  of  human  performance  and 
workload.  The  objective  of  SIMWAM  is  to  analyze  a  network  of  tasks 
that  comprise  the  basis  for  determination  of  crew  workloads,  individual 
workloads,  and  personnel  performance  problems. 

SIMWAM  consists  of  a  set  of  related  programs  that  permit  the  ana¬ 
lyst  to:  create  and  maintain  a  database  of  task  requirements;  execute  the 
task  network;  print  performance  data  following  the  network  execution; 
and  modify  the  task  data  to  evaluate  alternate  concepts.  Some  of  the 
features  of  SIMWAM  that  provide  the  resources  for  the  analyst  to 
model  an  existing  or  conceptual  system  include:  predecessor  relation¬ 
ships  between  tasks;  calls  for  execution  of  other  tasks  on  task  comple¬ 
tion;  specification  of  the  operator(s)  qualified  to  perform  each  task;  task 
interruption  in  case  of  operator  assignment  conflicts;  task  priorities  that 
control  operator  assignment;  and  Monte  Carlo  sampling  of  task  dura¬ 
tions  and  task  calls. 

During  a  SIMWAM  run,  tasks  are  called  when  prior  tasks  are  com¬ 
pleted.  If  sufficient  operators  are  available  for  a  called  task,  it  will  be 
started.  Input  data  describing  a  task  include  a  list  of  qualified  operators 
and  the  number  of  operators  required  to  perform  the  task.  In  attempting 
to  start  a  task,  SIMWAM  will  assign  capable  operators  who  are  cur¬ 
rently  idle.  SIMWAM  can  also  interrupt  lower-priority  tasks  in  process 
to  obtain  operators  for  higher-priority  tasks.  Operators  are  not  necessar¬ 
ily  human  operators  but  could  be  any  resource  entity. 

When  a  task  is  ready  to  start,  SIMWAM  draws  a  random  sample  from 
the  probability  distribution  of  duration  for  the  task.  While  the  task  is  in 
process,  operator  time  is  accumulated  on  the  task.  When  the  task  is 
completed,  it  can  call  other  tasks.  If  the  call  is  probabilistic,  then  one 
task  out  of  several  will  be  called  depending  on  specified  probabilities. 
Human  error,  equipment  failure,  or  a  hit  or  miss  following  weapon 
firing  are  events  that  could  be  accommodated  by  probabilistic  task  calls. 
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A  task  can  also  call  one  or  more  tasks  deterministically  when  a  fixed 
sequence  of  tasks  exists.  Task  calls  can  be  made  conditional  on  events 
or  variable  values  by  means  of  user- written  subroutines.  This  capability 
ensures  that  virtually  any  logical  conditions  for  the  start  of  a  task  can 
be  accommodated.  For  example,  tasks  required  to  process  objects  in  a 
queue  could  be  called  only  if  there  is  one  or  more  object(s)  in  the  queue. 
As  SIMWAM  executes  a  network  model,  it  tracks  mission  time,  task 
completions,  task  start  and  end  times,  time  spent  per  task  per  operator, 
and  operator  utilization  (sequence  of  events  showing  task  times  and 
operators;  summary  of  task  completions  and  operator  time  on  each  task; 
matrix  of  the  time  spent  on  each  task  for  each  operator;  and  summary  of 
active  and  idle  times  for  each  operator).  At  the  end  of  a  simulated  mis¬ 
sion,  these  data  can  be  printed.  At  the  end  of  a  simulation  run  involving 
a  number  of  missions,  the  means  and  standard  deviations  of  mission 
data  over  the  number  of  missions  run  can  be  printed. 

The  interactive  nature  of  SIMWAM  allows  the  analyst  to  evaluate 
alternate  system  designs  or  modifications  involving  manpower  reduc¬ 
tion,  cross  training,  automation,  task  modification,  or  function  alloca¬ 
tion.  SIMWAM  has  been  used  in  several  military  applications  to  iden¬ 
tify  the  potential  for  reducing  system  workloads  and  manning  levels. 

The  results  of  the  SIMWAM  simulation  exercise,  in  terms  of  work¬ 
load  and  expected  human  performance  problems,  are  provided  to  the  HSI 
Assessment  Tool,  ASSESS.  This  tool  supports  an  a.sse.ssment  of  alter¬ 
native  role-of-the-human  concepts  in  terms  of  affordability,  risk  reduc¬ 
tion,  and  expected  effectiveness.  The  affordability  assessment  addresses 
the  extent  to  which  affordability  objectives  arc  achieved  with  alternative 
approaches.  Affordability  objectives  from  an  HSI  perspective  should 
address  the  cost  risks  identified  for  each  alternative.  The  objectives 
should  encompass  reduced  acquisition  costs  and  reduced  life-cycle  costs. 
Reduced  acquisition  costs  include  cost  reductions  achieved  through  the 
integration  of  human  factors  engineering,  manpower/  pcrsonnel/training 
(MPT),  and  safety  and  health  design  considerations,  as  well  as  a  reduced 
need  to  redesign.  Reduced  life-cycle  costs  are  achieved  through  reduc¬ 
tions  in:  manning,  training  time,  career  progression  “pipelines,”  re¬ 
quirements  for  new  training  facilities,  accident  rates,  human  error  rates, 
time  to  repair,  supportability  requirements,  system  down  time,  and  per¬ 
sonnel  nonavailability. 

The  HSI  risk  assessment  addrc.sscs  cost,  schedule,  and  design  risks 
asscK'iatcd  with  the  role-of-the-human  concept.  Current  human-.system 
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cost  drivers,  MPT  drivers,  human  performance  drivers,  and  safety  high 
drivers  are  identified  for  each  concept,  and  trade-off  decisions  are  deline¬ 
ated.  Critical  human-system  factors  are  identified  in  design  alternatives 
that  will  have  a  significant  impact  on  readiness,  life-cycle  costs,  sched¬ 
ule,  or  performance.  These  factors  include:  tasks,  task  sequences,  and 
task  complexity;  environments  and  environmental  controls;  equipment 
design  features;  maintenance  requirements;  information  requirements; 
user-computer  interface  features;  manning  requirements;  workloads; 
personnel  skill  levels;  training  requirements;  and  health  and  safety  haz¬ 
ards.  Subsystems  or  components  associated  with  each  role-of-the-human 
concept  will  be  evaluated  for  high  or  moderate  risks. 

The  assessment  of  the  effectiveness  of  each  role-of-the-human  concept 
begins  with  an  analysis  of  outstanding  HSI  issues  and  concerns  from 
each  HSI  domain.  The  relative  criticality  of  each  issue  or  concern  identi¬ 
fied  is  established.  Finally,  recommendations  are  formulated  concerning 
the  changes  that  could  be  made  to  a  concept  to  improve  its  effective¬ 
ness. 

After  the  HSI  Assessment  Tool  is  applied,  the  results  of  the  assess¬ 
ments  and  any  recommended  changes  to  a  rolc-of-thc-human  concept  are 
then  fed  back  to  the  ROMAN  Tool  for  analysis  and  evaluation. 

APPLICATIONS 

The  techniques  and  tools  described  above  have  been  implemented  in 
several  HSI  attempts  to  reduce  manning  in  Navy  systems. 

REDUCTION  OF  MANNING  IN  AIRCRAFT  CARRIER  (CV) 

AIR  MANAGEMENT 

A  study  conducted  for  NAVSEA  by  Carlow  International  (Malone  et 
al.,  1986)  involved  the  application  of  decision-aiding  techniques  in  the 
form  of  automated  status  boards  to  reduce  the  manning  levels  of  aircraft 
carrier  (CV)  aircraft  management  systems.  This  effort  also  resulted  in 
the  development  of  the  workload  simulation  tool  SIMWAM  for  meas¬ 
urement  of  the  impact  of  human  factors  engineering  design  changes  on 
system  manning.  The  CV  aircraft  management  system  includes  thirty- 
five  operators.  A  scenario  for  exercise  of  this  system  was  developed, 
with  emphasis  on  the  variables  affecting  human  performance,  for  a  se¬ 
quence  involving  twelve  aircraft  launches  and  thirteen  recoveries. 
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A  SIMWAM  simulation  was  conducted  for  a  scenario  currently  im¬ 
plemented  in  the  fleet.  After  tasks,  sequences,  and  times  to  perfonn 
were  verified  in  a  ship  visit  (USS  Constellation),  the  simulation  was 
completed  for  the  baseline  condition.  The  sequences  inherent  in  the 
network  of  tasks  were  then  adjusted  to  reflect  changes  due  to  the  intro¬ 
duction  of  automated  status  boards  (ASTABs)  as  decision-aiding  de¬ 
vices,  and  a  second  simulation  run  was  completed  with  the  ASTAB  aids 
in  place.  The  complete  array  of  tasks  perfonned  by  all  operators  was 
analyzed  prior  to  conducting  the  second  SIMWAM  run  with  ASTABs 
included. 

A  comparison  was  made  of  the  operator’s  active  time  with  and  with¬ 
out  ASTABs.  The  results  of  this  comparison  indicated  that  four  opera¬ 
tor  positions  could  he  eliminated  due  to  the  reduction  in  workload  fol¬ 
lowing  introduction  of  the  ASTAB  aid.  Results  also  indicated  that 
twenty-live  of  the  remaining  thirty-one  operators  were  able  to  accom¬ 
plish  assigned  aircraft  management  tasks  in  less  time  with  the  ASTAB 
than  without  it.  This  finding  is  statistically  significant  at  beyond  the 
.001  level.  As  for  the  magnitude  of  the  time  change  from  run  1 
(without  ASTAB)  to  run  2  (with  ASTAB),  it  was  found  that,  on  the 
average,  operators  completed  assigned  tasks  in  run  2  in  20.6  percent 
less  time  as  compared  with  run  I. 

REDUCTION  OF  MANNING  IN 

NEW  ATTACK  SUBMARINE  SHIP  CONTROL 

Carlow  International  also  recently  conducted  an  effort  for  NAVSEA 
to  reduce  manning  levels  for  the  New  Attack  Submarine  (NAS)  ship 
control  system.  The  thrust  of  this  task  was  twofold:  (a)  to  apply  HSI 
methods  and  data  to  resolve  whether  ship  control  tasks  could  be  con¬ 
ducted  adequately  under  representative  scenarios  with  two  operators 
rather  than  four  operators  as  in  the  baseline  Sea  wolf  system;  and  (b)  to 
determine  operator  workloads  associated  with  the  reduced  manning. 

A  description  of  the  baseline  ship  control  system  (Seawolf)  was  de¬ 
veloped  that  included:  the  roles  and  responsibilities  of  the  four  operators 
and  other  crew  members  involved  in  system  operations  (c.g.,  officer  of 
the  deck);  the  alf(x:ation  of  ctmtrol  function  and  authority  to  human 
cemtred,  semiautomated  control,  or  fully  automated  control;  the  work¬ 
stations  pnwided  to  each  operator  and  the  human-machine  interface  fea- 
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tures  associated  with  each  workstation;  and  time  estimates  or  con¬ 
straints  associated  with  specific  tasks  and  task  sequences. 

NAS  normal  and  contingency  missions,  conditions,  and  operations 
were  identified  and  were  used  in  scenarios  to  assess  alternative  automa- 
tion  concepts.  A  task  sequence  was  developed  for  the  baseline  system 
for  selected  scenarios  using  the  IDEA  NETWORK  Tool.  Parameters 
associated  with  each  operator  task  were  identified  based  on  inputs  from 
subjeet-matter  experts.  Parameters  include  maximum  and  minimum 
time  to  perform  tasks,  task  dependencies,  and  the  effects  of  continuous 
operations  on  performance. 

Workloads  associated  with  Seawolf  operators  for  each  scenario  were 
assessed  using  SIMWAM.  Operators  included  those  performing  the 
functions  of  hclm/planes  watch,  ballast  control,  diving  officer  of  the 
wateh,  chief  of  the  watch,  and  officer  of  the  deck. 

Feasible  alternative  approaches  for  reduced-manning  ship  control  were 
then  identified  using  the  concepts  already  developed  in  the  description  of 
alternate  ship  control  system  design  approaches.  The  roles  of  humans  in 
the  alternate  automation  concepts  were  determined  using  the  IDEA 
ROMAN  Tool.  Task  sequences  for  each  ship  control  station  automation 
concept  were  established  for  selected  scenarios  for  the  two  ship  control 
operators  and  all  other  personnel  involved  in  ship  control  activities 
(c.g.,  the  officer  of  the  deck),  and  levels  of  specific  task  parameters  were 
identified  using  IDEA  NETWORK.  Workload  and  performance  assess¬ 
ments  for  each  alternative  concept  were  conducted  using  IDEA 
SIMWAM.  Feasible  concepts  were  evaluated  using  the  IDEA  HSI  As¬ 
sessment  Tool  to  conduct  assessments  of  (a)  alternative  concept  effec¬ 
tiveness  (operability,  usability,  maintainability,  safety/survivability, 
and  supportability);  and  (b)  risk  potential  associated  with  each  concept, 
including  design  risks,  cost  risks,  schedule  risks,  and  technology  risks. 

REDUCTION  OF  MANNING  IN  ADVANCED  SEALIFT  SHIPS 

Carlow  International  is  currently  supporting  NAVSEA  (SEA  03D7) 
in  the  application  of  IDEA  tools  to  reduce  manning  and  improve  the 
HSI  aspects  of  Fast  Sealift  ships.  A  major  contributor  to  the  overall 
effectiveness  of  Sealift  ships,  systems,  and  missions  is  the  performance 
and  readiness  of  the  Sealift  ship  crew.  The  HSI  initiative  addresses  per¬ 
sonnel  requirements  in  Sealift  ship  design.  The  driving  objective  of  HSI 
is  to  influence  design  with  regard  to  personnel  requirements  and  con- 
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siderations.  This  is  achieved  through  an  approach  that,  as  described 
above,  ensures  that  personnel  considerations  are  addressed  early  in  sys- 
tern  development,  that  emphasizes  attention  to  the  role  of  the  human 
vs.  automation  in  system  operation  and  maintenance,  and  that  uses 
simulation  to  model  human  performance  and  workload. 

Ancillary  objectives  of  HSI  as  applied  to  the  Sealift  program  are: 

(a)  reduced  personnel  requirements  as  compared  with  baseline  systems; 

(b)  improved  readiness  of  Sealift  ships  due  to  reduced  skill  requirements, 
reduced  workloads,  and  task  simplification; 

(c)  improved  reliability  of  Sealift  ships  and  ship  systems  due  to  an  em¬ 
phasis  on  software  and  a  reduction  of  human  error  rates; 

(d)  improved  personnel  availability  and  survivability  due  to  nxluoed 
hazards  and  accidents; 

(e)  enhanced  system  and  equipment  availability  through  reductions  in 
time  to  repair;  and 

(0  enhanced  system  affordability  through  a  reduction  in  personnel  sup¬ 
port  costs,  training  costs,  costs  of  systems  unavailability,  costs  of 
human  errors,  and  costs  of  accidents. 

Activities  to  be  accomplished  in  the  effort  include:  developing  a  les¬ 
sons  learned  database;  tracking  HSI  issues  in  existing  Sealift  ships; 
identifying  roles  of  humans  and  automation  in  selected  Sealift  mission 
scenarios;  conducting  function  and  task  analyses  for  selected  role-of-the- 
human  concepts;  identifying  alternate  approaches  to  reducing  manning 
levels  in  specific  Sealift  systems;  determining  requirements  to  modify 
licensing  procedures;  determining  training  requirements;  conducting  HSI 
assessments;  and  conducting  HSI  and  reliability  analyses. 

The  specific  requirements  and  constraints  to  be  addressed  in  applying 
HSI  technology  to  the  Future  Technology  Variant  Fast  Sealift  ship 
acquisition  include  the  following: 

•  high-reliability  equipment,  which  will  result  in  a  reduced  need  for  a 
human  backup  capability,  and  at  the  same  time  will  reduce  the 
maintenance  burden  and  the  workload  imposed  on  maintenance  per¬ 
sonnel; 

•  training  pipelines  that  will  assure  ready  availability  of  trained  fx^r- 
sonnel  in  the  numbers  and  time  frame  required  while  minimizing 
the  time  to  complete  training; 
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•  reduced  shipboard  manning  levels  that  address  reduction  of  workload 
by  automating  tasks  currently  performed  manually  and  moving  to 
shore  establishments  activities  currently  performed  on  board,  as 
well  as  applying  HSI  technology  such  as  decision-support  systems, 
job  performance  aids,  task  simplification  techniques,  and  on-line 
intelligent  tutoring; 

•  reduced  skills  required  to  perform  tasks  in  a  reduced  manning  envi¬ 
ronment,  through  application  of  HSI  technology  such  as  decision- 
support  systems,  job  performance  aids,  task  simplification  tech¬ 
niques,  and  on-line  intelligent  tutoring; 

•  personnel  career  progression  and  advancement; 

•  integration  and  consolidation  of  rates  and  ratings  that  will  result 
from  reduced  manning; 

•  emphasis  on  influencing  design  based  on  a  ship,  system,  and 
equipment  design  philosophy  that  envisions  the  role  of  the  human 
as  decision  maker,  systems  manager,  and  overall  supervisor,  and 
the  role  of  the  machine  as  encompassing  that  of  worker; 

•  focus  on  total  ship  as  well  as  ship  system  and  equipment  acquisi¬ 
tion,  as  opposed  to  ship  system/equipment  acquisition  alone; 

•  emphasis  on  user  acceptance,  with  the  user  viewed  as  encompass¬ 
ing  the  military  organization  responsible  for  Sealift  operations,  the 
commercial  ship  owner/operator,  and  the  on-board  human  operator 
and  maintainer; 

•  integration  of  HSI  technology  into  ship  and  system  acquisition 
through  implementation  of  a  standardized  and  formalized  HSI  proc¬ 
ess  that  is  itself  an  application  of  the  systems  engineering  ap¬ 
proach. 

The  application  of  HSI  to  the  Sealift  Future  Technology  Variant  pro¬ 
gram  will  be  accomplished  over  a  three-year  period.  The  products  of  the 
effort  that  will  be  available  at  the  end  of  this  three-year  period  are  as 
follows: 

(1)  HSI  issues  and  constraints  for  the  Sealift  program; 

(2)  ship  operational  procedures  for  reduced  manning  levels; 

(3)  results  of  HSI  technology,  effectiveness,  affordability,  and  risk 
assessments; 
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(4)  training  requirements  based  on  existing  licensing  procedures; 

(5)  reduced  manning  concepts  for  electric  systems,  propulsion  sys¬ 
tems,  auxiliary  machinery,  ship  control,  and  ship  services  such  as 
food  service;  existing  Sealift  ships  require  manning  levels  of  thirty 
to  forty  persons;  the  goal  in  HSl  application  is  to  reduce  manning 
levels  to  twelve  to  fifteen  people,  for  a  manning  reduction  of  up  to 
70  percent; 

(6)  ergonomic  design  of  integrated  consoles  for  single  operators  for 
electric  and  propulsion  systems,  auxiliary  machinery,  and  ship 
control; 

(7)  innovative  messing,  inventory  control,  and  stowage  concepts; 

(8)  strategies  to  effect  revised  US  Coast  Guard  (USCG)  regulations, 
and  requirements  to  revise  USCG  regulations  and  to  accommodate 
union  requirements; 

(9)  requirements  for  curriculum  changes  and  a  model  curriculum  for 
reduced-manning  ships; 

(10)  final  requirements  to  revise  USCG  regulations; 

(11)  validation  of  reduced  manning  and  manpower  determination  proc¬ 
esses  and  tools. 
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MANAGEMENT  OF  FUNCTION  ALLOCATION 
DURING  PROJECT  DEVELOPMENT 

P.  Aymar 


In  functiofi  allocation,  as  in  any  other  human  factors  tech¬ 
nique,  there  are  matiy  unanswered  questions.  Partial  answers 
do  exist,  however,  and  can  be  useful  for  system  design,  pro¬ 
vided  they  are  compatible  with  the  logic  of  project  manage¬ 
ment.  This  paper  offers  .some  guidelines  by  describitig  how 
human  factors  can  be  managed  in  a  project.  The  main  steps  in 
project  management  are:  definition  of  a  project  strategy, 
specification,  concept  developtuent,  and  evaluation.  The 
need  for  techniques  to  simulate  differefit  schemes  of 
task/function  allocation  is  pointed  out. 


INTRODUCTION 


Function  allocation  is  a  proven  soTtwarc  development  methodology. 
Transposing  it  to  hardware  or  human-maebinc  interl'aee  development  is 
not  as  easy  a.s  one  would  expect,  however.  While  computer  memory  can 
be  nearly  infinite  and  aeeomniodate  multiplication  of  modules,  the  real 
world  is  finite;  a  work.station  has  a  limited  number  of  slots,  and  obvi¬ 
ously  a  human  has  a  limited  number  of  Ungers,  arms,  and  cognitive 
abilities  as  well.  This  paper  provides  a  few  hints  for  exploring  how  the 
coneept  of  function  allocation  translates  to  human  factors,  using  man¬ 
agement  as  a  guideline. 

Project  management  is  a  process  that  ensures  that  a  satisfactory  piXKl- 
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uct  will  be  delivered  at  an  acceptable  cost  and  schedule.  It  relies  on  four 
main  steps: 

•  definition  of  a  strategy  based  on  risk  management  considerations; 

•  specification  of  what  has  to  be  done; 

•  concept  development; 

•  control  of  the  concept  development  process  and  products. 

The  main  management  tools  are  the  functional  spiecification,  the 
technical  specification,  and  the  evaluation  program. 

For  each  of  these  steps,  the  initial  phases  of  the  program  are  crucial 
(this  is  where  10  percent  of  the  money  is  spent,  and  90  percent  of  the 
choices  are  committed).  In  these  phases,  the  only  representations  of  the 
project  available  are  some  futuristic  concepts  used  to  justify  funding, 
the  functional  description,  and  occasionally  some  mock-ups.  The  func¬ 
tional  description  is  the  only  one  with  contractual  relevance.  The 
"functional"  approach  thus  has  special  importance  because  it  forms  the 
basis  for  a  common  language  for  development  and  for  the  evaluation  of 
the  deliverables;  it  includes  all  the  cases  of  the  word,  such  as  “function 
allocation.” 


PROJECT  STRATEGY 


The  project  manager's  task  is  to  handle  risks,  which  may  come  from 
management,  technique,  operation,  etc.  Risk  management  is  a  disci¬ 
pline  in  itself  with  its  own  experts.  From  a  human  factors  standpoint, 
however,  the  basic  considerations  include: 

•  level  of  detail  of  the  specification; 

•  methods  and  tools  mandated; 

•  control  level  and  communication  support; 

•  coordination/cooperation  among  project  actors. 

The  last  item  is  the  most  crucial.  Paradoxically,  it  is  human  factors 
people  who  suffer  most  when  there  are  deficiencies  in  this  human  fac¬ 
tors  element.  One  strategy  can  be  to  set  up  human  factors  databases 
providing  a  common  and  validated  view  of  the  project.  Fiches  oper- 
ateurs  and  fiches  equipement  are  used  for  this  purpose  in  France.  Nev- 
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crthclcss,  a  common  understanding  of  human  factors  objectives  is  nec¬ 
essary. 

One  formulation  of  such  an  objective  is  to  make  the  system  and  its 
various  subsystems  usable;  for  instance,  if  we  consider  a  ship,  it  must 
be  usable  by: 


•  The  Navy  through 


•  The  crew  and  through 

work  teams 


•  Individual  through 

operators 


-  Human  resources 
management 

-  Training 

-  Organization  of 
collective  activities 

-  Communications 

-  Habitability  and  living 
conditions 

-  Operability  of  systems 

-  Work  conditions 


The  knowledge  required  can  be  summarized  by  citing  the  domains  for 
MANPRINT  (Manpower  and  Personnel  Integration  program): 

•  human  factors  engineering; 

•  manpower; 

•  personnel; 

•  training; 

•  system  safety; 

•  health  hazards; 

•  basie  mcth(xls. 

MANPRINT  suggests  a  way  to  implement  human  factors  by 
organizing  the  debate  around  the  use  of  the  system  (the  “how”),  because 
this  is  where  technical  people  and  human  factors  people  meet.  Different 
points  of  view  exist  in  a  program  (see  Figure  12.1).  The  problem  is  to 
organize  cooperation  among  the  groups  with  these  different 
perspectives. 


o 

3: 


Figure  12.1.  Viewpoints  in  a  system  development  program. 
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For  instance,  on  a  CM  system: 


•  Architects 


think  about 


-  Technical  objects 
(hardware) 


•  Programmers  think  about 


-  Functional  objects 
(softwiirc) 


•  Users 


think  about 


-  Opcrating/opcrable 
objects  (liveware) 


An  implementation  program  that  would  allow  these  actors  to  com¬ 
municate  can  be  structured  as  shown  in  Figure  12.2. 

The  human  factors  expert  or  the  project  manager  would  then  ensure 
the  execution  of  the  program,  providing  expert  advice  centered  on  the 
work  activity. 


SPECIFICATION 


Specifications  can  be  functional  or  technical,  depending  on  the  in¬ 
tended  point  of  application  in  the  design  process.  Specifications  arc 
developed  through  the  elaboration  of  functional  concepts  and  design 
information.  In  a  top-down  approach,  functional  analysis  must  be  sup¬ 
ported  by  detailed  technical  infomiation.  Infonnation  must  be  compiled 
from  various  sources,  which  may  include  the  results  of  an  analysis  of 
current  systems,  mock-ups,  prototypes,  or  prospective  or  equivalent 
systems.  This  synthesis  of  tasks  and  activities  helps  to  organize  a  nego¬ 
tiation  between  operator-oriented  and  technical-orientcd  segments  of  the 
work  organization. 

The  following  is  an  example  of  a  discussion  that  might  ensue; 

Human  resources  representative:  “I  prefer  to  keep  the  old  system  be¬ 
cause  the  operators  are  trained  to  use  it." 

Technical  reprc.se nta live:  “Yes.  But,  as  you  can  sec,  operations  are 
much  simpler  with  this  system,  so  you  need  less  people." 

Human  resources  rcprcsenlalive:  ‘  I  understand.  It  would  suit  us  belter 
if  you  transfer  this  task  to  the  operator,  so  that  we  arc  sure  he  won’t 
lose  his  skills."  ... 


Area  of  responsibility 


Level  of  detail 


Figure  12.2.  Communication  between  areas  of  responsibility.  A  horizontal  arrow  represents  the  communication 
and  control  process  (consistency  checks,  for  example).  A  vertical  arrow  represents  the  application  of  methods  and 
tools. 
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The  synthesis  process  could  be  illustrated  as  follows: 

In  major  projects,  such  as  building  a  ship,  there  are  many  subcontrac¬ 
tors.  The  specification  is  not  only  a  system  description,  it  also  forms 
the  basis  for  the  contract  allocation  with  all  its  constraints:  evaluation, 
design  responsibilities,  and  money.  These  contract-sharing  considera¬ 
tions  quite  often  dominate,  because  they  reflect  industrial  know-how  and 
market  reality  (which  has  always  had  a  strong  influence  in  NATO  coun¬ 
tries).  However,  contract  allocation  always  has  a  strong  impact  on  ei¬ 
ther  function  allocation  or  integration.  In  both  cases,  the  choices  have 
consequences  for  the  future  operator.  They  will  sometimes  influence  the 
homogeneity  of  human-machine  interfaces.  They  can  also  determine 
which  organization  will  support  the  operator  in  such  areas  as  training, 
career  management,  selection,  ranks,  and  grouping.  The  process  of  func¬ 
tion  allocation  increasingly  takes  into  account  the  consequences  of  such 
choices  on  the  operability  of  the  future  system.  Distributed  models 
(MicroSAINT,  etc.)  help  in  considering  these  factors.  It  would  also  be 
useful,  however,  to  integrate  a  wider  range  of  human  factors  considera¬ 
tions,  for  example,  skill  acquisition — and  why  not  also  include  job 
satisfaction  and  personal  achievement? 

CONCEPT  DEVELOPMENT 

Concept  development  is  usually  the  obscure  phase  of  structured  top- 
down  approaches  such  as  those  induced  by  functional  analysis.  Innova¬ 
tion  is  not  consistent  with  function  allocation,  which  encounters  an 
intrinsic  difficulty  at  this  stage:  the  next  step  should  be  to  allocate  func¬ 
tions  to  the  design  objects.  But  which  objects?  What  is  needed  is  itera¬ 
tion  with  a  bottom-up  approach  in  which  candidate  objects  can  be  se¬ 
lected.  The  selection  of  objects  would  be  more  accurate,  while  the 
functional  chunks  would  become  larger  and  more  structured.  So  far  so 
good,  and  this  is  globally  the  scheme  used  by  my  fellow  engineers. 
This  process,  however,  tends  to  ignore  the  synergistic/antisynergistic 
properties  of  systems  and  the  possible  benefits  of  redundancies. 

There  is  a  constant  need  throughout  the  project  to: 

•  structuralize  functions; 

•  evaluate  the  impact  of  different  conceptions  on  the  integrated 
system. 
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Figure  12.3.  The  synthesis  process  from  need  to  specification. 
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There  are  many  analysis  methodologies  (object  oriented,  Petri,  se¬ 
mantic,  cognitive,  etc.).  They  offer  alternative  perspectives  of  the  sys¬ 
tem:  What  is  it  used  for?  In  what  state  is  it?  What  is  it  doing?  What 
information  does  it  use?  They  help  to  structure  system  functions  accord¬ 
ing  to  the  reference  chosen.  At  the  other  end,  prototypes  and  integration 
platforms  help  to  represent  the  function,  its  technical  implementation, 
and  the  user,  in  their  working  environment. 

EVALUATION 

The  evaluation  process  continues  throughout  the  project.  Evaluation 
matrices  are  available,  and  quite  a  few  are  found  in  the  literature.  Every 
human  factor  exp)ert  has  his  or  her  own,  depending  on  background  (e.g., 
nuclear,  CM,  aircraft).  The  job  of  the  manager  is  to  define  the  matrix 
most  appropriate  to  the  given  system,  and  to  quality  and  risk  manage¬ 
ment  objectives.  Then  the  manager  needs  to  implement  an  evaluation 
plan  that  will  help  in  controlling  the  work  and  deliveries  of  the  subcon¬ 
tractors.  Basic  evaluation  methodology  includes  verification  of  compli¬ 
ance  with  standards,  operability  checks,  and  user  trials.  The  following  is 
an  example  of  a  matrix  for  evaluating  warship  systems: 

•  Op)erability 

Human-machine  interface  devices 
Workstation  facilities 
Help  devices 

•  Teamwork 
Operator  role 
Workload 
Communication 

•  Work  conditions 
Layout 
Environment 
Hygiene 
Security 

•  Human  resources  requirements 
Number 

Selection 

Training 
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Evaluation  should  occur  at  all  stages  of  development  of  the  system. 
User  trials  of  prototypes  and  mock-ups  should  be  scheduled  to  address 
the  human  factors  issues  listed  above.  Before  mock-ups  or  prototypes 
have  been  produced — for  example,  in  the  concept  development  and  de¬ 
sign  stages — the  only  things  to  evaluate  are  the  functional  description 
of  the  system  and  the  suitability  of  the  proposed  technical  solution  with 
respect  to  required  overall  performance.  Modeling  of  the  distributed  sys¬ 
tem,  when  it  is  carried  out  with  enough  methodological  and  experimen¬ 
tal  care,  is  a  way  to  validate  such  virtual  systems.  The  function  alloca¬ 
tion  itself,  including  all  its  implications  for  the  operation  of  the 
system,  should  be  evaluated.  This  may  include  human-machine  interac¬ 
tion,  task  redundancies,  and  allocation  of  tasks  among  operators.  The 
evaluation  should  take  into  account  external  data  such  as  use  scenarios, 
performance,  and  reliability  of  imposed  concepts  of  equipment  and  or¬ 
ganization. 

CONCLUSIONS 

Function  allocation  is  more  than  a  design  feature,  it  is  a  major  con¬ 
cern  to  project  management.  Function  allocation  should  be: 

•  a  specification  tool; 

•  a  basis  for  contract  allocation  and  evaluation; 

•  a  tool  for  communication  and  dialogue  among  project  actors. 

It  can  also  be  a  design  tool  extending  the  top-down  approach  to  the 
definition  of  the  physical  or  visual  subsystems  of  the  human-machine 
interface.  Function  allocation  must  also  be  reliable,  and  methodologies 
should  include  evaluation  and  performance  indicators. 

With  adequate  support  and  management  tools  such  as  human  factors 
planning  and  supervision,  a  project  manager  is  able  to  integrate  human 
factors  into  the  course  of  work.  Function  allocation  would  then  play  an 
important  part  in  this  process;  but  the  consequences  of  each  function 
allocation  alternative  on  future  activity  need  to  be  made  clear.  The  chal¬ 
lenge,  of  course,  is  to  include  human  factors  engineering  considerations 
such  as  the  operability  and  habitability  of  the  system.  Techniques  like 
modeling,  CAD/CAM,  and  scale  1  mock-up  offer  fair  support  in  such 
endeavors.  A  wider  range  of  human  factors  issues  also  needs  to  be  con¬ 
sidered,  however,  such  as  teamwork  and  integration  into  the  user’s  or¬ 
ganization  (the  Navy  in  the  case  of  ships).  The  latter  offers  the  toughest 
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challenge  but  also  the  greatest  rewards;  it  will  show  the  rationality  and 
cost-effectiveness  of  considering  factors  like  skill  acquisition,  job  satis¬ 
faction,  and  personal  achievement. 
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FUNCTION  ALLOCATION  TRADE-OFFS: 
A  WORKLOAD  DESIGN  METHODOLOGY 

M.  L.  Swartz  and  D.  F.  Wallace 


ft  is  well  known  that  humans  perform  certain  tasks  better  than 
machines  and  that  machines  perform  other  tasks  better  than 
humans.  In  systems  design,  however,  allocation  of  tasks  be¬ 
tween  human  and  machine  is  not  straightforw’ard.  Tools  and 
heuristics  exist,  but  more  robust  function  allocation  tools  are 
needed.  The  Workload  Analysis  Aid  (WAA)  of  MAN -SEVAL 
(Manpower-Based  System  Evaluation  Aid)  can  be  used  to 
model  operator  performance  to  facilitate  function  allocation 
trade-offs.  The  US  Navy  is  using  such  technology  to  under¬ 
stand  function  allocation  and  workload  relationships  in  tacti¬ 
cal  display  design.  Traditional  engineering  approaches  often 
involve  automating  functions  without  regard  to  human  factors 
and  the  operator's  performance  limits.  This  paper  discusses  a 
series  of  function  allocation  trade-off  studies  based  on  a  hu¬ 
man  engineering  analysis  of  operator  performance.  Results 
are  presented  in  the  context  of  operator  workload  with  refer¬ 
ence  to  display  design  solutions. 


INTRODUCTION 

Deciding  how  to  allocate  control  of  system  functions  in  real-time, 
highly  automated  tactical  environments  that  enable  operators  to  perform 
optimally  is  essential  to  good  huinan-engincercd  design.  The  NATO  Sea 
Sparrow  Missile  System  (NS SMS)  is  being  redesigned  to  accommodate 
its  integration  into  the  Ship  Self-Defense  Program.  The  NSSMS  is 
already  highly  automated,  with  semiautomatic  modes  of  operation  for 
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certain  tactical  situations.  The  current  design,  however,  was  not  human- 
engineered  to  take  into  account  operator  performance  requirements.  To 
address  this  issue,  we  looked  at  human  performance  criteria  and  function 
allocation  trade-offs  in  the  NSSMS  so  that  the  redesigned  human-system 
interface  would:  (1)  follow  human  factors  engineering  design  principles 
and  (2)  support  optimal  operator  performance. 

In  the  current  design,  NSSMS  operators  are  faced  with  a  host  of 
tasks,  each  competing  for  attention  during  a  mission.  Two  task  condi¬ 
tions  present  workload  problems  for  operators:  electronic  countermea¬ 
sures  (ECM)  and  LOCAL  (manual)  control  of  target  acquisition  func¬ 
tions.  In  an  ECM  environment,  workload  is  increased  because  additional 
processing  demands  (e.g.,  monitoring  an  ECM  scan  for  targets)  are  im¬ 
posed  on  operators.  LOCAL  control  functions  are  performed  infre¬ 
quently,  but  their  impact  on  operator  performance  is  high.  This  mode  of 
operation  in  the  current  NSSMS  design  requires  that  operators  manually 
control  certain  tasks  (e.g.,  target  search).  LOCAL  control  under  ECM 
conditions  further  compounds  this  workload  and  places  the  greatest  de¬ 
mands  on  operators.  Some  functions  that  are  not  currently  automated 
should  be;  others  need  to  remain  under  operator  control.  This  scenario 
presented  the  basis  of  our  workload-based  function  allocation  trade-offs. 

NSSMS  FUNCTIONS  AND  OPERATOR  CONTROL 

NSSMS  radar  sensors  locate  a  target,  automatically  track  it,  and  guide 
the  missile  to  the  target  location  when  it  is  fired.  The  system  is  operated 
by  two  individuals.  The  firing  officer's  console  (FOC)  operator  is  re¬ 
sponsible  for  supervising  tracks,  missile  management,  and  launcher 
assignment  data.  The  radar  set  console  (RSC)  operator  also  supervises 
some  dynamic  processes  and  is  responsible  for  most  ECM  and  LOCAL 
control  tasks.  Automatic  computer  control  of  NSSMS  processes  oper¬ 
ates  at  high  data  rates  to  carry  out  speeifie  system  functions  efficiently 
and  accurately  while  the  operators  monitor  these  processes.  The  assump¬ 
tion  for  these  "system  supervisors"  is  that  they  sample  the  relevant 
information  at  a  sufficient  rate  to  make  an  appropriate  intervention  deci¬ 
sion.  The  problem  for  the  human  operator,  however,  is  twofold.  First, 
we  know  from  human-information-proeessing  theory  that  humans  have 
limited  resource  capacity  in  terms  of  the  amount  and  type  of  information 
they  ean  process.  Second,  operators  ean  introduce  noise  into  a  system's 
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closed-loop  feedback  system  if  information  is  not  sampled  at  adequate 
rates  (Moray,  1986)  or  if  simply  the  wrong  information  is  processed. 

For  example,  the  RSC  operator  monitors  system  status  data  and  as¬ 
signed  tracks  during  target  tracking.  As  the  operator  supervises  system 
processes,  he  or  she  may  have  to  make  a  decision  and  interrupt  the  .sys¬ 
tem  control  loop,  such  as  in  the  ease  where  target  priorities  change.  In 
mission-critical  situations,  we  can  say  the  operator’s  workload  for  these 
tasks  is  high.  Under  ECM  conditions,  workload  will  incrca.se  even 
more.  Often  the  RSC  operator  needs  to  assume  manual  control  so  that 
electronic  countcr-countcrmcasurcs  (ECCM)  can  he  taken.  The  operator's 
strategies  for  handling  high  workload  may  affect  supervisory  perform¬ 
ance.  The  operator  may  not  monitor  processes  effectively,  may  decide  to 
change  task  order,  or  may  even  drop  nonessential  tasks. 

An  intuitive  design  solution  for  these  potential  errors  may  he  to  real¬ 
locate  the  tasks  and  monitored  information  more  equitably  between  the 
two  operational  stations  (RSC  and  FOC).  This  solution,  however,  can¬ 
not  he  accomplished  adequately  within  the  constraints  of  the  existing 
system,  or  without  analyzing  the  supervi.sory  control  aspects  and  their 
related  information-processing  requirements  for  both  NSSMS  operators. 
The  reallocation  of  tasks  is  not  straightforward  (Sheridan,  1988).  It  must 
he  based  on  .sound  human  factors  engineering  principles  for  supervisory 
control  paradigms  and  must  he  integrated  within  the  system  engineering 
design  for  the  NSSMS.  Incremental  function  reallocation  trade -ofls  will 
provide  an  understanding  of  how  workload  is  distributed  across  tasks  and 
between  operators  when  taking  control  of  the  autonomous  control  loops 
in  NSSMS.  This  incremental  analysis  will  also  provide  preliminary 
assessment  of  human  resource  requirements  for  the  system  as  part  of 
Ship  Self-Defense  when  certain  functions  become  automated  that  cur¬ 
rently  arc  not. 

MULTIPLE-RESOURCE  THEORY  AND  WORKLOAD 

Multiple-resource  theory  (Wickens,  1986)  provides  a  framework  for 
describing  the  various  resource  channels  that  NSSMS  operators  utilize 
to  perform  mission  tasks,  and  a  means  for  assessing  the  total  load  upon 
the  operator  at  any  one  time.  This  theory  states  that  attention-processing 
resources  are  limited  and  must  he  allocated  among  all  tasks  performed  by 
an  individual.  As  workload  increases,  this  limited  capacity  pool  of  re¬ 
sources  may  no  longer  be  able  to  provide  the  attention  and  proce.ssing 
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needs  for  the  task(s).  Each  resource  channel  (auditory,  visual,  cognitive, 
psychomotor)  is  viewed  as  a  distinct  processing  system,  so  that  an  indi¬ 
vidual  can  be  fully  ’’loaded"  on  one  channel  when  the  full  capacity  of 
that  channel  is  utilized  (e.g.,  listening  to  a  Doppler  shift  signature  loads 
the  auditory  channel)  yet  still  be  able  to  undertake  an  additional  load  on 
other  channels  (e.g.,  reading  range  rate  on  the  display  loads  the  visual 
and  cognitive  channels)  without  performance  decrement  on  either  task. 

Capacity  limits  for  each  channel  can  be  defined  by  the  number  of 
"bits"  of  information  that  can  be  processed  in  any  one  of  the  four  re¬ 
source  channels.  This  limit  of  7±2  bits  of  information  is  well  known  in 
the  experimental  psychology  community.  Function  allocation  trade-offs 
based  on  an  analysis  of  these  capacity  limits  will  enable  us  to  design 
console  displays  that  present  information  in  ways  that  best  support  the 
operator  and  his/her  cognitive  capabilities. 

We  approached  this  display  design  problem  by  conducting  a  detailed 
analysis  of  operator  performance  that  included:  (1)  an  assessment  of 
operator  task  requirements  and  workload;  (2)  a  trade-off  analysis  of  sys¬ 
tem  functions  to  reallocate  tasks  among  the  appropriate  number  and  type 
of  operators,  including  automation;  and  (3)  a  design  guideline  report 
describing  the  necessary  input  devices  and  information  displays  to  sup¬ 
port  NSSMS  operators  as  supervisory  controllers  of  system  processes. 
This  paper  presents  the  results  from  task  items  1  and  2. 

STUDY  DESIGN 

We  developed  exemplar  mission  scenarios  to  identify  realistic  naval 
threats  for  ECM  and  LOCAL  control  conditions.  We  video-recorded 
these  simulated  scenarios  with  actual  NSSMS  operators  at  two  Navy 
sites  for  subsequent  analysis.  Control  conditions  (no  ECM  and  semiau¬ 
tomatic  [no  LOCAL]  control)  were  also  video-recorded  and  used  as  a 
workload  baseline. 

PARTICIPANTS 

Naval  personnel  with  NSSMS  operations  and/or  training  experience 
were  recruited  from  naval  bases  in  Oxnard,  CA,  and  Chesapeake,  VA. 
All  participants  had  received  training  on  NSSMS  systems.  Some  of  the 
participants  were  NSSMS  instructors.  The  level  of  NSSMS  operator 
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console  experience  ranged  from  1  to  9  years;  operators  with  actual  com¬ 
bat  experience  were  not  available. 

APPARATUS  AND  MATERIALS 

Video  cameras  were  used  to  capture  operator  performance  during  this 
study.  All  scenarios  were  generated  using  the  NSSMS  training  simula¬ 
tor  and  were  run  on  FOC  and  RSC  consoles  and  other  NSSMS  hardware 
to  ensure  the  validity  of  our  findings.  Paper-and-pencil  questionnaires 
were  also  employed  for  the  structured  interviews.  A  human  performance 
modelling  tool,  Workload  Analysis  Aid  (WAA),  which  is  a  component 
of  the  Manpower-Based  System  Evaluation  Aid  (MAN-SEVAL)  (Army 
Research  Institute,  1992),  was  used  to  run  simulations  of  the  modeled 
NSSMS  tasks  and  to  conduct  function  reallocation  trade-offs  between 
automation  and  the  human  operators. 

PROCEDURES 

Videotaped  Scenarios,  All  operators  were  informed  as  to  the  pur¬ 
poses  of  the  study  and  provided  informed  consent  to  participate  in  this 
investigation.  Operators  were  asked  to  perform  a  suite  of  representative 
NSSMS  tactical  engagement  scenarios  including  operations  in  both 
ECM  and  non-ECM  environments,  semiautomatic  and  LOCAL  opera¬ 
tions,  and  prosecution  of  air  and  surface  targets.  All  representative  sce¬ 
narios  were  run  in  real  time,  and  operator  actions  were  videotaped.  The 
videotapes  were  time-stamped,  and  specific  task  times  were  calculated  for 
each  mission  scenario. 

Operator  Interviews,  After  all  scenarios  were  completed,  operators 
were  interviewed  to  assess  the  operational  models  used  by  the  NSSMS 
operators  and  clarify  any  actions  performed  during  the  tactical  simula¬ 
tion.  The  interviews  were  also  used  to  elicit  discussion  of  any  difficul¬ 
ties  operators  have  had  in  using  the  current  system  and  any  suggestions 
or  "wish  lists"  operators  might  have  for  improvements,  features,  and 
enhancements  to  the  display  and  console. 

WAA  Human  Performance  Models,  Descriptive  human  performance 
models  for  both  the  FOC  and  RSC  operators  were  built  using  the  WAA 
tool.  The  videotaped  scenarios  were  used  to  capture  the  true  task  per¬ 
formance  and  to  provide  task-time  data.  Each  function  and  its  constituent 
tasks  were  assigned  the  appropriate  time.  NSSMS  experts  assisted  in  the 
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verification  of  these  models  and  time  on  task  to  ensure  accuracy.  Under 
each  major  function,  tasks  and  subtasks  were  listed  and  organized  into 
either  serial  or  parallel  sequencing  with  other  tasks.  Where  mission- 
defined  branching  occurred,  appropriate  probabilities  were  assigned  for 
each  branch.  Performance  times  and  WAA-derived  resource-channel  val¬ 
ues  were  also  assigned  for  each  task.  Each  model  was  run  and  the  work¬ 
load  results  analyzed.  After  a  model  was  built  and  analyzed,  the  WAA 
tool  permitted  reallocation  of  tasks  between  operator  and  automation 
within  a  particular  model.  This  capability  was  utilized  to  model  per¬ 
formance  in  a  suite  of  function  allocation  trade-offs. 

RESULTS 

Descriptive  performance  models  were  run  for  all  study  conditions 
(semiautomatic  versus  LOCAL,  ECM  versus  no  ECM).  These  models 
provide  an  objective  description  of  task-analysis-derived  performance  and 
are  not  to  be  construed  as  predictive  models  of  operator  behavior.  All 
tasks  under  each  condition  were  assigned  with  resource-channel  values  to 
identify  the  complexity  of  the  tasks.  Results  plotted  workload  into  his¬ 
tograms  for  each  channel's  loading  per  task.  WAA  also  provided  task- 
overload  summary  results  for  each  simulation  model.  Due  to  the  varied 
nature  of  the  ECM  environment,  multiple  contingencies,  and  the  fact 
that  some  of  the  activities  are  classified,  we  decided  to  model  ECCM 
tasks  in  WAA  as  a  continuous  function,  parallel  within  the  other  func¬ 
tions,  that  can  occur  at  any  time  for  up  to  the  full  duration  of  the  coin¬ 
cident  function.  The  ECCM  workload  values  were  modeled  separately 
and  a  composite  set  of  workload  weightings  derived.  We  set  a  limit  for 
each  channel  of  7  bits  to  ensure  the  control  of  potential  workload  in  the 
new  design. 

Each  simulation  run  resulted  in  a  total  mission  time  of  4  minutes  42 
seconds,  well  within  the  set  limits  of  the  defined  mission  time  of  4 
minutes  50  seconds  (which  includes  3  minutes  for  tuning  the  missiles). 

OVERALL  WORKLOAD 

Workload  was  highest  during  ECM  for  both  operators  as  predicted. 
The  RSC  operator  had  greater  workload  in  both  LOCAL  control  and 
ECM  conditions  in  general  as  compared  to  the  FOC  operator.  The  FOC 
operator  had  greater  workload  during  certain  functions  in  both  condi- 
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tions,  but  this  was  due  to  added  verbal  communication  tasks  with 
personnel  and  normal  state  verification  of  console  indicators,  not  real¬ 
time  tactical  demands  incurred  in  either  LOCAL  control  or  ECM.  The 
effects  of  overall  workload  for  both  NSSMS  operators  are  illustrated  in 
Figures  13. 1  and  13.2.  Here  we  show  a  simple  additive  model  that  sums 
the  loads  across  all  four  channels.  If,  for  example,  each  processing  chan¬ 
nel  was  loaded  at  7  bits  of  information,  the  operator  would  be  fully 
loaded  at  28  (4  channels  x  7  bits).  This  is  not  to  assume  that  a  value  of 
28  or  less  is  acceptable,  but  rather  to  illustrate  that  any  combined  work¬ 
loads  of  greater  than  28  are  excessive  and  cannot  be  sustained  by  an 
operator  for  any  period  of  time. 

Research  suggests  that  specific  workload  channel  overloading  is  not 
the  only  factor  to  be  considered  in  examining  operator  performance 
(Huey  &  Wiekens,  1993).  Operators  can  sometimes  cope  with  heavy 
workload  in  one  channel  by  shifting  tasks  to  other  processing  resources 
or  eliminating  tasks.  If  all  channels  are  heavily  loaded,  the  operator's 
coping  options  are  reduced.  Post-experiment  interviews  revealed  that 
some  operators  used  such  coping  strategies,  but  this  type  of  analysis 
was  not  pursued  further  in  this  research. 

SPECIFIC  TASK  AND  CHANNEL  LOADINGS 

Next  we  discuss  the  specific  tasks  on  which  high  workload  occurs  and 
the  specific  resource  channels  that  are  affected  for  each  NSSMS  operator. 
Since  the  worst-case  scenario  for  workload  is  when  the  system  is  under 
LOCAL  control  in  an  ECM  environment,  this  discussion  will  focus 
upon  that  condition. 

An  analysis  of  FOC  operator  workload  revealed  that  the  cognitive  and 
visual  channels  are  most  often  overloaded.  Further  analysis  revealed  that 
the  majority  of  the  visual  overloads  and  many  of  the  cognitive  overloads 
were  directly  traceable  to  prescribed  observations  of  system  status 
indicators,  as  in  both  system  readiness  and  target  engagement  tasks.  Of 
the  remaining  overload  conditions,  our  analysis  showed  that  many  of 
these  were  transient  "spikes"  of  increased  workload  as  opposed  to  a 
sustained  workload  over  long  periods  of  time.  The  particular  functions 
with  the  most  sustained  workload  are:  target  tracking  (where  missile 
management  decisions  are  made),  target  engagement  (firing  of  missile), 
and  post-fire  evaluation  (determination  of  appropriate  actions  to  perform 


Figure  13.1.  Firing  officer’s  console  (FOC)  operator  workload  for  LOCAL  control,  no  ECM  condition  (white 
area)  and  LOCAL  control,  ECM  condition  (gray  area).  The  x-axis  depicts  mission  time  and  system  functions;  the 
y-axis,  an  additive  scale  of  bits  of  information.  Excessive  workload  is  above  28,  a  combined  total  for  the  four  indi¬ 
vidual  channels  assessed. 


Figure  13.2,  Radar  set  console  (RSC)  operator  workload  tor  LOCAL,  no  ECM  condition  (white  area)  and  LOCAL, 
ECM  condition  (gray  area).  Same  scale  as  for  Figure  13.1. 
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based  upon  tactical  situation,  ship's  doctrine,  and  engagement  outcome). 

A  different  pattern  of  workload  was  seen  for  the  RSC  operator.  Again, 
the  visual  and  cognitive  channels  were  most  often  overloaded  across 
tasks,  but  a  substantial  psychomotor  load  was  also  encountered  occa¬ 
sionally  during  target  tracking.  Even  the  auditory  channel  was  over¬ 
loaded  during  target  tracking  when  Doppler  audio  cues  and  speech  (FOC- 
RSC  communications)  were  processed  simultaneously.  As  with  the 
FOC  operator,  visual  observation  of  normal  system  status  indicators 
contributed  to  high  workload.  Unlike  the  FOC  operator,  however,  the 
RSC  operator  is  subjected  to  a  more  sustained,  elevated  workload.  Some 
of  the  specific  functions  that  contributed  to  prolonged  extreme  loading 
were:  target  search  (where  many  visual  and  cognitive  resources  are  de¬ 
manded  to  identify  target  video  returns),  target  acquisition  (psychomotor 
demands  for  dual  cursor  controls,  one  rotary,  one  linear),  target  tracking 
under  ECM  conditions  (visual  and  cognitive  resources  demanded  to 
maintaining  target  return,  identify  ECM  encountered,  and  counter  ECM, 
all  at  the  same  time),  and  post-fire  evaluation  (kill/survive  decisions). 

TASK  REALLOCATION  TRADE-OFFS 

Based  on  the  above  results,  we  ran  a  series  of  function  allocation 
trade-offs  using  the  WAA  tool  to  reallocate  selected  tasks  in  the  LOCAL 
control  mode  between  the  two  NSSMS  operators  with  different  levels  of 
additional  NSSMS  automation.  We  also  examined  a  trade-off  between  a 
single  NSSMS  operator  and  additional  NSSMS  automation  as  a  first 
step  in  identifying  appropriate  personnel  levels  for  NSSMS  operation  in 
the  new  system  design. 

We  ran  the  function  allocation  trade-offs  with  the  LOCAL  con- 
trol/ECM  models  because  task  demands  for  this  condition  pose  perform¬ 
ance  problems  for  operators  during  the  stress  of  actual  engagement.  This 
was  also  confirmed  in  the  results  presented  above.  In  addition,  many 
LOCAL  control/ECM  tasks  are  not  currently  automated  in  the  existing 
NSSMS  design.  Since  the  visual  and  cognitive  channels  were  the  two 
that  arc  most  highly  loaded  in  these  conditions,  we  were  interested  in 
reallocating  tasks  with  those  resource  requirements.  The  WAA  tool 
allowed  us  to  reassign  tasks  and  then  run  the  simulations  to  model  the 
redistributed  tasks.  Workload  histograms  were  again  plotted  and  thresh- 
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old  levels  assessed.  In  these  trade-offs,  as  before,  we  used  7  bits  of  in¬ 
formation  as  the  maximum  allowable  limit  for  any  one  resource  channel 
at  any  one  time. 

In  the  first  trade-off,  we  assigned  all  of  the  system  verification  and 
monitoring  tasks  across  all  functions  to  automation.  These  visual  tasks 
were  unnecessary  and  accounted  for  a  great  deal  of  the  excessive  load  for 
both  operators.  Our  design  work  is  looking  at  display  methods  that 
reduce  these  task  demands  through  more  efficient  information  presenta¬ 
tion  (Swartz  &  Wallace,  1994).  This  trade-off  showed  that,  overall, 
both  operators’  workload  was  reduced  as  indicated  in  Figures  13.3  and 
13.4.  These  levels  arc  dramatically  lower  when  compared  to  workload 
levels  for  the  baseline  allocation  of  tasks  for  LOCAL  control/ECM 
conditions  shown  above  in  Figures  13.1  and  13.2.  The  system  readiness 
function  and  all  constituent  tasks  in  this  trade-ofl  were  below  the  7-bit 
threshold  for  both  operators.  The  FOC  operator  experienced  a  high 
workload  spike  in  the  target  acquisition  and  post-fire  evaluation  func¬ 
tions.  The  RSC  operator’s  workload  began  with  the  target  search  func¬ 
tion  as  a  high,  discrete  spike  and  then  remained  high  through  the  rest  of 
the  mission. 

Consistent  with  the  previous  workload  results,  the  visual  and  cogni¬ 
tive  resource  channels  continued  to  experience  excessive  workload  cb- 
spite  these  automation  trade-offs.  Clearly,  more  function  allocations  to 
automation  arc  needed  in  order  to  reduce  the  load  to  more  manageable 
levels. 

Under  the  next  function  reallocation  trade-off,  we  included  increased 
automation  of  additional  tasks  for  both  operators  based  on  some  of  the 
workload-reduction  techniques  we  were  developing  for  the  new  console 
displays.  Examples  include:  (1)  transformation  of  target  data  observa¬ 
tions,  mental  conversions,  and  calculations  from  three  separate  display 
indicators  to  a  single  graphical  display  that  automatically  provides  a 
synthesized  result;  and  (2)  redesign  of  more  complex  selection  and  motor 
tasks  (c.g.,  determination  and  transfer  of  track  to  a  target-launched 
weapon,  or  integration  of  bearing  and  range  rate  controls  into  a  unified 
multiplc-dcgree-of-freedom  input  device).  These  display  solutions  for  the 
new  NSSMS  console  design  arc  described  further  elsewhere  (Swartz  & 
Wallace,  1994). 

The  results  of  the  simulation  run  showed  a  dramatic  drop  in  workload 


Figure  13.3.  Channel  workload  levels  for  the  FOC  operator  when  a  minimal  function  allocation  trade-off  is  used. 
Excessive  workload  is  reflected  where  workload  exceeds  7  (bits)  on  an  individual  channel  or  28  overall. 


Figure  13.4.  Channel  workload  levels  for  the  RSC  operator  when  a  minimal  function  allocation  trade-off  is  used. 
Excessive  workload  is  reflected  where  workload  exceeds  7  (bits)  on  an  individual  channel  or  28  overall. 
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for  the  FCXZ  operator  (see  Figure  13.5).  At  this  increased  level  of  auto¬ 
mation,  this  operator’s  maximum  workload  falls  below  the  7-bit  thresh¬ 
old.  The  RSC  operator's  high  workload  drops  to  about  half  of  the  origi¬ 
nal  workload  we  observed  (compare  Figure  13.6  with  Figure  13.2)  and 
is  less  than  that  incurred  in  the  first  trade-off  (Figure  13.4);  but  this 
operator  still  experiences  excessive  load  in  the  last  four  system  func¬ 
tions.  These  are  the  most  critical  functions  the  operator  must  perform. 
Consistent  with  previous  results,  the  cognitive  and  visual  channels  are 
still  heavily  loaded. 

We  next  looked  at  the  minimum  number  of  personnel  required  to 
operate  the  NSSMS.  For  this  analysis,  wc  examined  the  impact  of  allo¬ 
cating  all  remaining  tasks  to  a  single  operator  to  determine  if  such  a 
design  would  be  feasible.  Given  the  high  load  for  the  RSC  operator  in 
the  second  trade-off,  we  had  no  real  expectation  of  favorable  results  when 
the  FOC  tasks  were  added  to  this  position.  Nevertheless,  to  uncover  the 
problem  areas  for  a  potential  single  operator,  we  used  the  second  reallo¬ 
cation  scheme  described  above  and  reallocated  all  operator  tasks  to  a 
single  NSSMS  operator,  then  ran  the  simulation.  Some  tasks  involving 
coordination  between  operators  (e.g.,  FOC  to  RSC  communications) 
were  eliminated  since  they  were  inappropriate  to  a  single-operator  sys¬ 
tem.  This  analysis  was  further  bounded  by  an  assumption  of  a  single¬ 
radar,  single-launcher  configuration  (some  NSSMS  configurations  use 
two  launchers  and  require  two  operators). 

The  preliminary  WAA  analysis  indicates  that  combining  both  opera¬ 
tors'  functions  into  a  single  position  does  not  dramatically  increase  the 
workload  for  a  single  operator  (see  Figure  13.7).  In  fact,  the  overall 
workload  measure  for  the  single  NSSMS  operator  increases  only 
slightly  as  compared  with  that  of  the  RSC  operator  in  a  dual -operator 
configuration  with  the  equivalent  amount  of  automation.  Consistent 
with  all  the  RSC  trade-off  analyses,  however,  excessive  workload  at  this 
level  of  automation  remains  in  all  functions  from  target  tracking 
through  the  end  of  the  mission. 

CONCLUSIONS 

Results  from  the  task  analyses,  operator  workload  simulations,  and 
reallocation  trade-off  studies  we  conducted  consistently  identified  specific 
visual  processing  of  system  status  information  and  cognitive  decision¬ 
making  tasks  as  high  workload  areas  for  both  FOC  and  RSC  operators. 
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The  LOCAL  control  and  ECM  conditions,  as  predicted,  imposed  the 
most  workload  on  operators.  We  determined  that  many  of  the  high- 
workload  tasks  involved  verification  of  normal  system  operations  and 
could  therefore  easily  be  automated. 

The  transient  spikes  of  high  workload  for  the  FOC  operator  indicate 
that  this  operator  might  be  able  to  distribute  over  time  some  of  the 
tasks  associated  with  sudden  spikes.  This  problem  can  be  corrected  with 
workload-reduction  techniques  for  presenting  information  on  the  display. 
The  RSC  operator  has  the  highest  workload,  as  anticipated,  even  when 
increased  automation  is  introduced  into  the  operator  performance  models. 

While  the  workload  analysis  provided  an  assessment  of  individual 
tasks  that  continue  to  impose  high  workload  on  NSSMS  operators, 
specifically  for  the  visual  and  cognitive  channels,  the  task  reallocation 
U-ade-off  results  provided  a  view  of  the  impact  of  redistributing  tasks  on 
operator  workload.  These  analyses  reinforce  the  intuitive  conclusion  that 
increasing  automation  can  reduce  NSSMS  workload.  More  importantly, 
they  identify  which  specific  tasks  sustain  loading  and  which  processing 
channels  bear  the  load.  This  is  valuable  information  for  guiding  good 
human  factors  engineering  of  the  display  interface. 

Our  task- real  location  studies  indicate  the  [X)tential  for  consolidating 
operations  into  a  single  operator  position,  but  not  until  more  advanced 
automation  is  introduced  into  the  system  design.  A  solution  to  the  im¬ 
mediate  workload  problem  for  NSSMS  operators  is  to  redistribute  tasks 
more  appropriately  between  both  positions  and  to  implement  workload- 
reduction  techniques  for  presenting  information  on  the  console  displays. 
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FUNCTION  ALLOCATION  FOR  THE  DESIGN  OF 
A  RECONNAISSANCE  VEHICLE' 

D.  F.  Streets  and  R.  J.  Edwards 


The  twin  drives  of  reductions  in  available  human  resources 
and  technological  advance  have  combined  to  produce  pro¬ 
posals  for  vehicle  design  that  use  smaller  crew  complements. 
This  design  trend  has  also  revealed  the  shortcomings  in  the 
techniques  used  for  function  allocation.  One  graphic  demon¬ 
stration  can  be  found  in  the  recent  task-analysis  studies  of 
ground  recon-naissance  performed  by  Edwards  and  Streets 
( 1994).  In  these  .studies,  the  requirement  was  to  allocate  re¬ 
sidual  functions  among  crew  members,  rather  than  between 
human  and  technology.  This  report  documents  the  difficulties 
encountered  in  these  tasks  and  the  assumptions  that  had  to  be 
made,  and  discusses  how  observations  made  during  data 
gathering  enhance  function  allocation. 


INTRODUCTION 

The  activity  of  function  all(x:ation  is  central  to  any  predictive  task 
analysis,  yet  it  is  supported  by  relatively  imprecise  techniques  (e.g., 
Fitts’  lists)  that  appear  to  be  based  upon  intuition  rather  than  science.  A 
further  problem — and  one  that  is  assuming  increasing  importance — is 
that  current  techniques  do  not  address  team  interactions.  With  the  cur¬ 
rent  drive  to  reduce  personnel  levels  in  military  systems,  the  problem  of 
allocating  residual  tasks  takes  on  a  new  signifieancc. 

New  technology  seeks  to  enhance  system  effectiveness  by  removing 
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certain  tasks  or  subtasks  from  the  human  domain.  Technology  may,  for 
example,  increase  data  handling,  storage,  and  transmission  capability, 
but  it  cannot  replace  the  human  function  of  information  interpretation. 
What  technology  is  achieving  is  to  increase  the  operator’s  available 
time  by  performing  repetitive  and  time-consuming  tasks,  leaving  the 
operator  free  to  concentrate  on  more  intuitive  duties.  The  concept  is  that 
free  time  can  be  increased  to  the  point  where  the  residual  duties  of  one 
crew  member  can  be  redistributed  successfully  among  others,  thus  al¬ 
lowing  a  reduction  in  crew  complement. 

Available  function  allocation  techniques  fail  to  address  the  methods  of 
achieving  this  redistribution.  At  best,  an  ad  hoc  approach  may  be  em¬ 
ployed;  but  this  fails  to  address  team  dynamics  or  take  account  of  the 
nature  of  the  reallocated  tasks.  In  this  paper,  we  report  on  observations 
made  during  the  collection  of  task-analysis  data  from  an  active  recon¬ 
naissance  unit  that  highlights  an  area  function  allocation  techniques  fail 
to  address.  We  also  demonstrate  an  iterative  function  allocation  tech¬ 
nique  and  discuss  how  our  in-field  observations  are  being  applied,  at  a 
relatively  low  level,  to  improve  human-human  function  allocation. 

BACKGROUND 

The  principal  function  of  armored  medium  reconnaissance  is  to  pro¬ 
vide  timely  and  accurate  combat  information  to  higher  formations.  In 
the  British  Army,  the  base  vehicle  for  this  activity  is  the  Combat  Vehi¬ 
cle  Reconnaissance  (Tracked),  or  CVR(T),  which  has  three  crew  mem¬ 
bers — a  commander  and  gunner  located  in  the  turret,  and  a  driver  located 
in  the  hull.  Compared  with  the  rest  of  the  British  Army  armored  fleet, 
this  is  a  relatively  old  vehicle,  and  the  desire  is  to  replace  the  CVR(T) 
with  a  significantly  enhanced  vehicle,  the  Tactical  Recon-naissance  Ar¬ 
moured  Combat  Equipment  Requirement  (TRACER). 

The  design  of  TRACER  is  expected  to  take  full  advantage  of  recent 
advances  in  integrated  vehicle  electronics  architecture  (vetronics)  and 
military  equipment  technology.  The  philosophy  behind  vetronics  is 
very  similar  to  that  governing  avionics  in  high-performance  aircraft.  A 
central  processor  connects  each  system  and  subsystem  through  a  data 
bus  architecture.  This  arrangement  allows  system  integration  and  en¬ 
hanced  information  flow  and  exchange.  It  is  this  potential  increase  in 
information-processing  efficiency  that  offers  the  scope  for  reductions  in 
crew  workload  and,  possibly,  crew  numbers,  and  has  led  to  the  sugges- 
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tion  that  TRACER  could  possibly  have  a  crew  complement  of  two. 

The  Defence  Research  Agency  Centre  for  Human  Sciences  was 
charged  with  performing  a  series  of  task -analysis  activities  to  support 
studies  for  TRACER.  These  activities  have  been  reported  elsewhere 
(Edwards  &  Streets,  1994).  In  outline,  the  first  series  of  studies  were 
aimed  at  documenting  current  reconnaissance  practices,  while  the  second 
series  were  predictive  studies  that  spcciHeally  addressed  surveillance 
activities  based  on  the  best  available  information  on  scenarios  for  future 
deployment.  The  information  presented  in  the  second  series  would  be 
u.scd  as  a  design  tool  for  the  crew  workstations  within  the  vehicle.  It 
was  also  anticipated  that  the  analysis  would  indicate  areas  of  crew  work 
overload. 


CURRENT  RECONNAISSANCE 

The  overall  crew  tasks  of  a  CVR(T)  arc  oriented  toward  fulfilling  the 
primary  aim  of  reconnaissance.  Within  the  crew,  each  human  has  a  set 
of  well-defined  core  roles.  The  main  task  of  the  driver,  for  example,  is 
to  move  the  vehicle  tactically  using  the  fastest  and  safest  route  and 
without  causing  the  other  crew  memhers  undue  distress.  In  performing  a 
given  mission,  however,  crew  ccx)peration  is  paramount;  for  example, 
the  driver  may  also  he  expected  to  provide  route  information,  such  as 
ground  conditions,  state  of  bridges,  or  possible  ambush  points.  The 
operation  of  the  vehicle  depends  upon  close  cooperation  among  the  crew 
and,  in  particular,  the  commander  and  gunner.  The  nature  of  this  coop¬ 
eration  is  determined  by  the  scenario  and  by  a  set  of  rigidly  demarcated 
prcKedural  rules. 

Allocation  of  current  functions  among  the  crew  memhers  was  re¬ 
coaled  hy  structured  interview  of  serving  crews,  di.scussions  with  sub¬ 
ject-matter  experts,  and  participation  in  training  exercises  (Edwards, 
1992).  These  methods  produced  the  type  of  information  shown  in  Table 
14.1. 

The  uppcrca.se  X’s  refer  to  a  erew  member's  core  task,  while  the  low- 
crca.se  X’s  indicate  a  secondary  task  in  which  that  crew  member  might 
c(X)perate  with  another  or  in  which  systems  tasks  are  perfonned.  This 
relatively  simplistic  presentation  of  self-selected  function  allocation 
provided  the  ha.seline  data  for  subsequent  studies  and  also  revealed  some 
of  the  dynamics  of  duty  allocation  within  a  group. 
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Table  14.1.  Function  allocation  among  the  three-person  erew  in  a 
combat  reconnaissance  vehicle  [CVR(T)] 


TASK 

COMMANDER 

GUNNER 

DRIVER 

Surveillance 

X 

X 

X 

Radio  watch 

X 

X 

X 

Navigate 

X 

X 

Drive 

X 

Direct  driver 

X 

X 

Maintenance 

X 

X 

X 

Stowage 

X 

X 

X 

Start  up  drills 

X 

X 

X 

Cook 

X 

X 

X 

Encode/decode 

X 

X 

Range  cards 

X 

X 

X 

Lx)ad  gun 

X 

Fire  gun 

X 

X 

During  the  collection  of  these  data,  it  became  apparent  that  task  allo¬ 
cation  and  individual  workload  in  a  three-person  crew  are  driven  by  rank 
and  experience.  When  the  vehicle  is  in  motion,  the  commander  will 
perform  all  the  key  functions,  such  as  communications  and  surveil¬ 
lance.  The  gunner's  role  is  to  aid  the  commander;  it  is  rare  for  the  gun¬ 
ner  to  perform  any  command  function  unaided.  It  was  noted  on  many 
occasions  that  the  commander  used  the  map  to  mark  the  route  taken  and 
to  record  information  flow.  It  was  rare  that  other  crew  members  saw  or 
used  the  map.  Indeed,  the  only  tasks  that  were  generally  not  performed 
by  the  commander  were  driving  and  gunning. 

It  is  these  characteristics  that  make  function  allocation  in  a  reconnais¬ 
sance  vehicle  so  difficult.  Models  of  teamwork  (c.g.,  METACREW,  in 
Plocher,  1989)  work  to  a  set  of  command  rules  that  address  how  indi- 
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viduals  manage  work.  Task  sharing  and  switching  is  not  addressed,  nor 
are  any  procedural  rules. 

When  the  vehicle  is  stationary,  the  roles  of  surveillance  and  commu¬ 
nication  are  shared  among  the  crew.  This  is  known  as  the  “stag”  sys¬ 
tem.  In  this  case,  each  crew  member  will  take  equal  turns  at  each  sys¬ 
tem  task,  but  the  commander  will  have  overall  control  and 
responsibility.  This  very  tight  control  ensures  that  the  system  operates 
in  an  efficient  and  effective  manner,  and  it  is  the  basis  of  the  military 
training  system  for  reconnaissance  troops. 

The  rigidity  of  this  system  may  be  gauged  from  a  recent  trial  in 
which  reconnaissance  crew  members  were  presented  with  two  identical 
operational  crewstations  that  could  be  used  for  either  command  or  driv¬ 
ing  functions.  The  concept  was  that  tasks  could  be  switched  between 
members  in  response  to  changes  in  the  mission  scenario.  What  was 
observed  was  that  crew  functions  were  self-distributed  by  rank,  so  that, 
even  when  the  more  senior  soldier  was  performing  the  driving  function 
by  choice,  he  also  performed  the  traditional  command  functions;  the 
second  crew  member  merely  provided  support.  Although  this  may  be 
viewed  as  a  consequence  of  the  military  training  system,  it  does  high¬ 
light  a  significant  problem,  namely,  that  current  function  allocation 
techniques  cannot  lake  into  account  rank  and  experience  hierarchy.  It  is 
well  documented  that  rank  and  hierarchy  arc  powerful  determinants  of 
how  systems  actually  operate.  A  proper  understanding  of  these  dynam¬ 
ics  is  essential.  The  consequences  of  being  unable  to  account  for  rank 
and  hierarchy  in  function  allocation  is  illustrated  in  the  next  section. 

PREDICTIVE  TASK  ANALYSIS 

The  second  scries  of  task-analysis  studies  was  aimed  at  characterizing 
the  activities  associated  with  surveillance  and  engagement  tasks  in  a 
TRACER  concept  vehicle.  A  full  account  may  be  found  in  Edwards  and 
Streets  (1994). 

It  was  assumed  that  the  crew  would  be  designated  as  a  commander  and 
a  co-commander,  with  the  gunner’s  duties  being  shared  between  vetron- 
ics  and  the  two  remaining  crew  members.  A  further  assumption  was 
that  all  tasks  would  be  interchangeable  depending  upon  the  nature  of  the 
scenario.  Appropriate  scenarios  and  outline  equipment  performance  pa¬ 
rameters  were  made  available. 
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As  noted  above,  the  gunner’s  on- vehicle  duties  are  directed  at  support¬ 
ing  the  commander,  which  leaves  few  primary  tasks  to  be  performed 
totally  by  vetronics.  The  outcome  is  that  functions  are  allocated  primar¬ 
ily  between  the  remaining  crew  members’  primary  duties.  To  perform 
this  allocation,  a  set  of  task-synthesis  rules  that  characterized  the  re¬ 
maining  crew  members’  primary  duties  had  to  be  produced.  After  a 
working  taxonomy  was  established,  a  set  of  task-synthesis  rules  was 
derived.  These  were: 

(i)  Crew  are  referred  to  as  commander  and  co-commander.  The  com¬ 
mander  has  sole  control  of  communications  flow  into  and  out  of 
the  vehicle;  the  co-commander  has  sole  control  of  the  driving  func¬ 
tion,  These  primary  crew  functions  can  be  transferred  between  crew 
members  only  when  the  main  armament  is  manned  and  ready  for 
use. 

(ii)  Driving  is  an  autonomous  activity  and  the  co-commander  has  sole 
control  over  the  route  and  speed  at  which  the  vehicle  travels.  When 
driving,  the  co-commander  makes  no  primary  contribution  to  any 
other  surveillance  duties  except  route  reconnaissance  and  survey, 

(iii)  Unless  otherwise  stated,  the  co-commander  has  sole  responsibility 
for  off-vehicle  duties. 

(iv)  The  activities  of  driving  or  communications  cannot  be  combined 
with  engagement. 

(v)  The  activities  of  weapon  and  engagement  or  weapon  management 
and  driving  cannot  be  combined.  Weapon  management  is  defined  as 
keeping  the  main  weapon  in  readiness  when  the  vehicle  is  moving. 

(vi)  The  crew  member  who  makes  first  visual  contact  with  an  enemy 
objective  completes  the  engagement  sequence. 

These  rules  were  based  on  the  behavioral  premise  that  no  more  than 
two  dissimilar  manual  tasks  could  be  performed  simultaneously.  Cogni¬ 
tive  workload  could  not  be  taken  into  account  because  the  performance 
parameters  of  the  surveillance  devices  and  possible  data-handling  capa¬ 
bilities  of  the  vetronics  were  ill-defined.  Clearly,  it  is  impossible  both 
to  read  text  and  to  examine  a  picture  for  discrete  changes;  however,  it  is 
not  known  if  information  exists  on  the  ability  to  observe  a  scene  both 
for  driving  and  for  surveillance  purposes,  and  if  there  would  be  any  per¬ 
formance  decrement. 
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Table  14.2.  Core  duties  for  each  crew  member  in  a  CVR(T) 


COMMANDER 

CO-COMMANDER 

Surveillance 

Drive 

Communications 

Route  reconnaissance 

Survey 

Troop  security 

Navigation 

Survey 

Troop  security 

Weapon  management 

Troop  control 

Tabic  14.2  shows  the  core  duties  defined  for  each  crew  member  from 
these  task-synthesis  rules.  The  information  gained  from  our  earlier  stud¬ 
ies  was  used  to  enhance  this  allocation,  but  the  possible  effects  of  rank 
and  experience  were  purposely  ignored.  Because  the  task-analysis  exer¬ 
cise  was  concerned  with  surveillance  duties,  system  tasks  such  as  stow¬ 
age  and  maintenance  were  not  considered.  It  was  unnecessary  to  under¬ 
take  function  allocation  between  humans  and  surveillance  devices 
because  such  systems  enhance  human  performance — they  cannot  replace 
the  human.  Table  14.3  shows  an  attempt  to  allocate  other  equipment, 
by  function,  to  the  crew.  Performance  parameters  were  poor,  and  allega¬ 
tion  was  based  on  the  task-synthesis  rules  set  out  above.  “Primary 
User”  is  defined  as  the  crew  member  who  is  expected  to  be  the  priority 
user  of  that  system  under  all  conditions. 

The  formal  task-analysis  techniques  used  were  a  combination  of  func¬ 
tion  flow  diagrams  and  operational  sequence  diagrams.  Function  How 
diagrams  were  chosen  because  they  permitted  the  representation  of  in¬ 
formation  flow  and  could  be  altered  to  show  each  crew  member's  activ¬ 
ity.  The  basic  outline  for  each  function  flow  diagram  was  a  preparation 
phase,  a  number  of  activities  that  had  to  be  completed  to  fulfil  the  task, 
and  an  either/or  statement.  This  allowed  the  task  to  be  continually  recy¬ 
cled,  to  be  halted,  or  to  progress  on  to  a  related  activity.  Each  function 
flow  diagram  was  divided  into  three  parallel  flow  lines.  The  central  flow 
line  described  the  functionality  of  the  system  task.  System  tasks  were 
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Table  14.3.  Allocation  of  equipment,  by  function,  to  crew  members 
in  a  CVR(CT) 


EQUIPMENT 

PRIMARY 

USER 

SECONDARY 

USER 

Audio  and  digital  communications 

Commander 

Co-commander 

Battlefield  Management  System 

Commander 

Co-commander 

(BMS)  -  Moving 

BMS  -  Stationary 

Equal  priority 

Land  Navigation  System  (LNG)  - 

Co-commander 

Commander 

for  driving 

LNG  -  for  information 

Commander 

Co-Commander 

Electronic  Map  System  (EMS) 

Commander 

Co-Commander 

given  individual  reference  numbers  to  allow  a  degree  of  ordering.  To  the 
left  and  right,  respectively,  of  the  system  flow  line  were  the  commander 
and  co-commander  flow  lines.  Text  to  either  side  of  a  system  task  box 
indicated  the  duties  each  performed  in  accomplishing  each  activity. 
Concurrent  tasks  were  also  indicated  by  text  between  each  system  task 
box.  Information  flow  to  and  from  the  system,  and  from  outside  the 
system  (i.e.,  squadron,  or  section  headquarters,  SHQ)  to  each  crew 
member  could  be  represented  by  directional  arrows. 

A  total  of  fifteen  functional  flow  diagrams  supporting  identified  sur¬ 
veillance  tasks  were  derived.  An  example  is  shown  in  Figure  14.1.  This 
approach  allowed  visualization  of  the  tasks  each  crew  member  would 
need  to  perform  and  permitted  function  allocation  by  default.  The  prin¬ 
ciple  employed  was  that  a  task  could  only  be  performed  if  a  crew  mem¬ 
ber  was  available. 

The  output  of  the  function  flow  diagram  served  as  the  database  for  the 
formal  task  analysis.  A  review  of  task-analysis  methods  suggested  that 
the  most  appropriate  technique  would  be  the  operational  sequence  dia¬ 
gram,  since  it  can  represent  the  flow  of  information  (Beevis,  1992)  and 
show  individual  activities  of  teams  of  workers  performing  tasks 
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Commander's  tasks  System  tasks  Co-commander’s  tasks 


Figure  14.1.  Function  How  diagram  for  observation  (mobile). 
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(Laughery  &  Laughery,  1987).  Time-line  analysis  was  rejected  because 
of  its  imprecision;  flow  process  charts  and  hierarchical  methods  were 
rejected  because  of  their  relative  complexity,  particularly  for  the  repre¬ 
sentation  of  multiple  and  concurrent  tasks. 

The  function  flow  diagrams  represent  the  performance  of  single  tasks; 
interactions  are  shown  but  not  explored.  The  operational  sequence  dia¬ 
grams  were  able  to  visualize  these  interrelationships  and  identify  areas 
of  task  overload.  More  significantly,  they  were  able  to  show  the  extent 
to  which  tasks  would  need  to  be  shared  or  switched  to  allow  two  crew 
members  to  operate  the  system.  An  example  is  shown  in  Figure  14.2. 

The  scenario  supporting  this  operational  sequence  diagram  is  for  a 
static  observation  made  by  a  single  vehicle.  Support  is  denied,  so  the 
vehicle  is  required  to  carry  out  an  engagement  sequence  unaided.  The 
task-synthesis  rules  (above)  have  been  used  as  the  basis  for  determining 
how  tasks  arc  shared  and  switched.  The  two  prime  determinants  are  rules 
iii  to  vi,  which  set  out  primary  roles  and  forbidden  task  combinations. 
As  Figure  14.2  shows,  once  the  co-commander  has  prepared  the  vehicle 
to  move  and  has  remounted,  there  is  a  staged  hand-over  of  system  tasks 
until  the  commander's  sole  duty  is  control  of  the  weapon  system.  At 
the  end  of  the  engagement  sequence,  there  is  a  staged  return  of  duties. 

Although  this  allocation  appears,  superficially,  to  be  plausible,  there 
are  a  number  of  serious  faults.  At  the  commencement  of  the  engage¬ 
ment  sequence,  the  co-commander  may  be  expected  to  perform  up  to  ten 
tasks  or  subtasks,  while  the  commander  has  a  single  duty  to  undertake 
but  has  no  direct  communication  with  higher  formations.  It  is  hard  to 
imagine  that  a  commander  would  willingly  hand  over  duties  in  the 
manner  described,  but  the  absence  of  a  function  allocation  technique  that 
takes  account  of  rank  and  experience  could  lead  to  this  conclusion.  As¬ 
sumptions  made  from  this  example  could  be  erroneous  and  could  be 
translated  into  poor  equipment  design. 

We  have  reexamined  this  operational  sequence  diagram,  and  the  task- 
synthesis  rules,  in  the  light  of  our  observations  on  rank  and  experience 
as  significant  factors  in  determining  function  allocation  and  have  arrived 
at  revised  conclusions.  It  is  clear  that  a  further  task-synthesis  rule  needs 
to  be  drawn  up;  our  tentative  new  working  rule  at  present  is: 

(vii)  Rank  and  experience  dictate  that  the  commander  maintain  control 
of  communications  to  and  from  the  vehicle  at  all  times  when  the 
vehicle  is  in  motion.  When  the  vehicle  is  stationary,  control  may 
be  shared  between  the  crew. 
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1030 
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Squadron/section 

headquarters 


Commander 
Cdr  makes  contact 


Co-commander 


Figure  14.2.  Operational  sequence  diagram  for  task  switching. 
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Rule  iv  is  rewritten  as: 

(iv)  The  activity  of  driving  cannot  be  combined  with  engagement. 

The  outcome  of  these  rules  is  that  the  commander,  by  retaining  the 
communications  task,  may  maintain  control  of  the  vehicle  throughout 
the  engagement  sequence,  with  a  consequent  reduction  in  the  workload 
of  the  co-commander.  The  problem  with  this  iterative  approach  to  func¬ 
tion  allocation  is  that  a  suitable  test  of  validity  does  not  yet  exist.  Un¬ 
like  aviation  or  industrial  scenarios  where  missions  are  of  finite  length 
and  have  clearly  defined  goals,  in  military  land-based  systems  these  con¬ 
ditions  arc  not  normally  fulfilled.  Under  such  circumstances,  it  is  pos¬ 
sible  that  traditional  function  allocation  techniques  arc  inappropriate  and 
that  a  combination  of  intimate  knowledge  of  current  activities  and  the 
dynamics  controlling  crew  performance,  coupled  with  an  iterative  ap¬ 
proach,  is  the  only  valid  technique.  It  is  equally  possible  that  the  ap¬ 
proach  described  for  land-based  reconnaissance  is  valid  only  for  this  sys¬ 
tem. 


CONCLUSIONS 

This  paper  has  described  some  of  the  problems  encountered  in  at¬ 
tempting  to  perform  function  allocation  between  human  and  human, 
rather  than  human  and  machine,  in  a  ground-based  system.  At  a  time 
when  the  drive  appears  to  be  to  reduce  crew  levels,  it  is  essential  that 
new  techniques  for  human-human  function  allocation  be  derived.  A  ma¬ 
jor  factor  in  determining  function  allocation  in  a  three-person  reconnais¬ 
sance  crew  is  rank  and  experience.  This  factor  assumes  even  greater  sig¬ 
nificance  when  the  attempt  is  to  allocate  functions  to  a  two-person 
crew.  Whether  this  would  be  such  a  strong  determinant  if  human-human 
function  allocation  were  being  performed  on  a  reduced  crew  complement 
for  larger  systems  (e.g.,  self-propelled  guns)  remains  to  be  determined. 
From  the  evidence  outlined  in  this  paper,  it  is  suggested  that  the  first 
steps  in  deriving  techniques  must  be  to  clearly  define  the  system  and  to 
identify  the  high-driver  functions  and  the  acceptable  departures  from 
hierarchical  command  structures. 
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FUNCTION  ALLOCATION  FOR 
REMOTELY  CONTROLLED  MINESWEEPERS 

L.  C.  Boer 


Function  analysis  and  function  allocation  are  described  for  a 
new  minesweeping  system  based  on  remote  control  of 
'drones. "  The  critical  question  for  system  design  was 
whether  one  operator  on  board  a  mother  ship  could  manage 
four  drones  at  once,  using  remote  control.  The  results  of  a 
humandn-thedoop  simulation  revealed  which  conditions  of 
automated  support  produce  acceptable  performance  of  the 
human-machine  system.  A  general  conclusion  of  the  simula¬ 
tion  study  is  that  one  of  the  allocation  criteria  should  be  to 
utilize  the  human  mental  capacity  available,  even  when  the 
system  requires  only  a  fraction  of  this  capacity. 


INTRODUCTION 

In  a  study  for  the  Royal  Netherlands  Navy,  function  allocation  was 
performed  together  with  a  function  analysis  to  define  the  functions 
required  by  a  minesweeper  system  to  fulfil  the  system’s  mission.  The 
focus  of  analysis  was  the  role  of  the  human  operator.  Those  functions 
that  involved  a  human  operator  were  analyzed  in  more  detail;  functions 
not  involving  humans  were  not  analyzed  further.  Function  allocation 
and  function  analysis  were  thus  coupled  interactively,  as  shown  in 
Figure  15.1. 

The  function  analysis  was  hierarchical.  At  the  top  level,  the  complete 
system  was  addressed.  The  system,  consisting  of  four  “drone”  mine¬ 
sweepers  remotely  controlled  from  a  mother  ship,  needed  to  perform 
two  basic  functions:  minesweeping  and  navigation.  A  preliminary 
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Figure  15.1.  Interaction  between  allocation  and  analysis  of  function. 
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consideration  of  function  allocation  revealed  that  the  “minesweeping’' 
function  requires  no  human  involvement  except  for  a  minor  degree  of 
supervision  and  authorization  of  the  start  and  end  of  the  sweeping  opera¬ 
tion.  This  function  was  not  analyzed  further.  Human  involvement  was 
foreseen  in  the  “navigating”  function.  In  a  further  analysis,  a  distinction 
was  made  between  the  subfunction  “planning,”  which  provided  a  plan 
for  how  to  sweep  a  designated  area,  and  the  subfunction  “drone  control,” 
responsible  for  executing  the  plan.  Both  functions  require  human  in¬ 
volvement.  The  concept  of  remote  control  is  new  for  the  Royal  Nether¬ 
lands  Navy.  Thus,  the  subfunction  “drone  control”  required  special  at¬ 
tention,  as  shown  in  Figure  15.2.  Remote  control  is  an  attractive 
design  option,  first,  because  it  increases  the  safety  of  minesweeping 
and,  second,  because  it  promotes  reduction  in  forces,  which  is  a  long¬ 
term  policy  in  many  NATO  countries. 

“Tracking”  is  a  subfunction  concerned  with  keeping  the  drones  on 
their  designated  track.  ’’Speed  control”  is  a  subfunction  concerned  with 
maintaining  the  designated  speed.  “Platform”  is  concerned  with  the  in¬ 
tegrity  of  the  drones  and  their  technical  systems.  ‘Traffic”  is  concerned 
with  watching  out  for  other  vessels  and  evading  if  necessary. 

The  “platform”  and  “traffic”  subfunctions  take  into  account  particular 
aspects  of  the  environment.  Damage  to  the  drones’  platforms  is  not 
unlikely  considering  the  possibility  of  mines’  exploding  in  the  vicinity 
of  the  drones.  Other  traffic  is  not  unlikely  because  the  system  will  be 
designed  both  for  wartime  and  peacetime  operation.  In  peacetime,  other 
traffic  cannot  be  denied  access  to  the  area  to  be  swept.  Operator  in¬ 
volvement  was  deemed  necessary  because  the  “platform”  and  “traffic” 
subfunctions  require  flexibility  and  improvisation — functions  at  which 
humans  still  surpass  machines. 

A  simulation  of  the  drone-control  function  was  set  up  in  order  to  see 
whether  one  operator  could  control  four  drones  at  once,  managing  the 
four  subfunctions  outlined  above.  In  other  words,  the  operator  was  in¬ 
volved  not  only  in  extraordinary  situations  (platform  damage  or  danger¬ 
ous  traffic),  but  in  continuous  tracking  as  well.  One  reason  to  consider 
a  more  extensive  allocation  to  the  human  operator  is  financial  cost. 
Instead  of  automating  as  much  as  possible,  the  approach  advocated  here 
is  to  allocate  more  functions  to  the  human  operator  if  the  operator’s 
mental  capacity  allows  for  additional  activities.  This  saves  automation 
costs.  Moreover,  a  more  satisfying  job  is  created,  promoting  human 
well-being  (Drury,  1994;  see  also  Fitts,  1962).  Thus,  careful  allocation 


Figure  15.2.  Three  levels  of  function  analysis  for  a  minesweeper  system.  The  human  operator  in  the  subfunction 
“drone  control’’  is  the  focus  of  the  current  paper. 
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of  function  not  only  can  save  money  but  also  can  reduce  operator  frus¬ 
tration  and  boredom  as  well,  making  the  job  more  challenging. 

Two  types  of  simulation  can  be  used  to  assess  system  performance 
and  operator  workload:  fast-time  simulation  and  human-in-ihe-loop 
simulation.  In  fast-time  simulation,  a  computer  model  of  the  human 
operator  is  part  of  the  simulation.  Typical  parameters  include  the  time 
to  complete  an  action,  the  probability  of  success,  and  the  mental  load 
on  the  operator.  By  running  a  fast-time  simulation  many  times,  indica¬ 
tions  of  average  performance  of  human-machine  systems  can  be  ob¬ 
tained.  Fast-time  simulations  are  promising  tools,  but  somewhat  risky 
to  use  at  the  current  state  of  knowledge  about  human  factors.  The  prob¬ 
lem  is  that  the  human  factors  discipline  has  no  complete  model  for  op¬ 
erator  performance,  but  fast-time  simulation  requires  such  a  model.  As  a 
consequence,  unsound  and  questionable  assumptions  may  abound  in 
fast-time  simulation.  There  are  also  some  reasonable  assumptions;  for 
example,  for  simple  tasks  where  time  to  completion  conveys  all  the 
information  required,  or  for  tasks  known  in  great  detail,  such  as  cockpit 
tasks,  where  the  time  to  operate  each  individual  switch,  the  probability 
of  error,  and  the  mental  load  factor  are  known.  The  assumptions  arc 
weak  and  debatable,  however,  when  applied  to  complex  tasks  and  mul¬ 
titask  situations.  The  consequence  is  pseudoaccuracy.  The  simulation 
model  produces  accurate  time  lines  of  mental  workload,  but  their  valid¬ 
ity  is  questionable.  Attempts  at  fast-time  simulation  ba.sed  on  informa¬ 
tion-processing  models  of  human  performance  such  as  the  Goals,  Op¬ 
erators,  Methods,  Selections  (GOMS)  model  (Card,  Moran,  &  Newell, 
1986)  are  under  way,  but  it  is  not  yet  clear  whether  this  is  a  viable  al¬ 
ternative. 

Human-in-thc-loop  simulation  uses  a  computer  model  of  the  system 
together  with  a  real  human  operator.  The  flight  simulator  is  the  classi¬ 
cal  example:  a  real  pilot  operates  a  simulated  airplane,  Human-in-the- 
loop  simulation  requires  a  “reaf’  interface  between  human  and  machine; 
the  development  of  an  interface  was  part  of  the  project.  (Fast-time 
simulations  do  not  require  human-machine  interfaces.)  The  advantage  of 
human-in-the-loop  simulation  is  the  presence  of  real  humans  with  real 
mental  capacity,  which  frees  us  from  the  assumptions  associated  with 
fast-time  simulation. 

For  these  reasons,  the  present  study  used  a  human-in-the-loop  simula¬ 
tion.  In  the  simulation,  both  system  performance  and  operator  workload 
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were  measured.  Performance  criteria  for  operational  acceptability  were 
formulated  in  advance. 


SIMULATION 

Apparatus.  There  were  two  displays,  one  for  tracking,  the  other  for 
the  remaining  tasks.  A  special  control  panel  was  used  for  tracking,  and 
a  mouse  and  the  computer  keyboard  were  used  for  the  other  tasks.  Fig¬ 
ure  15.3  shows  the  setup. 

Subjects.  Eleven  young  adults  participated  as  paid  subjects.  On  day  1 , 
they  were  trained  on  the  tasks;  on  day  2,  they  performed  the  tasks  for 
data  collection. 

Tasks.  The  tasks  allocated  to  the  subject  were:  (a)  tracking,  (b)  plat¬ 
form,  and  (c)  watching.  Speed  control  was  automated;  the  drones  sailed 
at  a  constant  speed.  The  tracking  task  was  presented  with  various  de¬ 
grees  of  automated  support.  Control  by  rudder  was  the  lowest  level  of 
automated  support;  control  by  a  course  autopilot  was  the  medium  level; 
and  course -autopilot  control  plus  presence  of  a  path  predictor  was  the 
level  just  below  full  automation.  A  high-quality  "radar  view"  on  the 
first  display  showed  the  position  of  the  designated  track  relative  to  the 
individual  drone.  Figure  15.4  gives  an  idea  of  this  human-machine  in¬ 
terface.  For  the  highest  automation  level,  a  line  protruding  from  the 
drone  showed  the  path  prediction  for  the  coming  20  seconds.  The  de¬ 
pendent  variable  was  the  deviation  between  the  actual  path  and  the  des¬ 
ignated  track. 

The  sweeping  plan  contained  a  number  of  straight  tracks.  The  sce¬ 
nario  specified  wind  (constant)  and  current  (different  for  different  parts  of 
the  area).  Both  wind  and  current  were  at,  or  close  to,  the  limits  consid¬ 
ered  just  acceptable  by  the  Royal  Netherlands  Navy. 

The  platform  and  watching  tasks  used  the  second  display.  They  were 
represented  with  some  abstraction  because  the  details  of  these  tasks  were 
not  known  at  the  time  of  the  experiment.  The  platform  task  was  to 
react  to  "alarms"  presented  every  4  minutes.  An  acoustic  alarm  annunci¬ 
ated  the  alarm.  At  the  same  moment,  one  of  the  three  windows  in  the 
upper  part  of  the  display  was  illuminated.  The  subject  had  to  extinguish 
the  window  by  clicking  it  with  the  mouse.  Then,  one  of  the  other  win¬ 
dows  was  illuminated  and  had  to  be  clicked.  Finally,  a  third  window 
was  illuminated  and  had  to  be  clicked.  After  these  three  actions,  a  two- 
number  addition  was  presented.  The  subject  had  to  enter  the  solution 


Figure  15.3.  The  simulation  setup.  Displays  are  for  platform  and  watching  (left)  and  tracking  (right;  see  Figure 
15.4  for  more  detail). 


272 


Improving  Function  Allocation 


Figure  15.4.  The  radar  view  for  the  tracking  task. 

using  the  keypad  of  the  computer.  The  dependent  variables  were  the 
number  of  correct  solutions  and  the  time  between  the  alarm  and  the 
“Enter”  command. 

The  watching  task  was  to  monitor  arrows  appearing  every  20  seconds 
in  the  lower  half  of  the  second  display.  Subjects  had  to  react  by  press¬ 
ing  the  space  bar  if  an  arrow  p>ointed  anywhere  between  cast  and  south. 
The  dependent  variable  was  the  number  of  missed  target  arrows. 

The  instruction  was  to  sail  the  drones  over  their  designated  track,  to 
react  to  platform  alarms,  and  to  watch  for  target  arrows.  There  were  six 
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conditions  defined  by  the  three  levels  of  tracking  automation  and  the 
number  of  drones  under  control  (two  or  four).  The  platform  and  the 
watching  task  were  the  same  across  the  six  conditions.  Each  condition 
lasted  30  minutes.  The  order  in  which  the  conditions  were  presented  was 
randomized  across  subjects. 

Mental  workload  was  measured  subjectively.  Immediately  after  a  con¬ 
dition,  the  subjects  were  asked  to  report  their  mental  effort  as  a  number 
between  I  (no  workload)  and  5  (very  high  workload).  These  univariate 
ratings  are  at  least  as  sensitive  as  multivariate  ratings  (Hendy,  Hamilton 
&  Landry,  1993).  Moreover,  univariate  ratings  are  easier  to  collect  and 
to  process. 

RESULTS 

Tracking.  Figure  15.5  shows  the  interval  around  the  designated  track 
within  which  the  drones  sailed  95  percent  of  the  time.  The  figure  also 
shows  the  standards  of  operational  acceptability.  The  level  of  automa¬ 
tion  is  indicated  along  the  x-axis.  At  the  extremes,  the  results  are  very 
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Figure  15.5.  Tracking  performance  as  a  function  of  automation  level 
with  control  of  two  drones  or  four  drones.  (The  dashed  lines  show  the 
boundaries  of  operational  acceptability.) 
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clear;  tracking  performance  was  unacceptable  for  the  lowest  level  of 
automation,  rudder  control;  tracking  performance  was  acceptable  for  the 
highest  level  of  automation,  course-autopilot  control  aided  by  path  pre¬ 
diction.  These  results  held  regardless  of  whether  the  subject  controlled 
two  or  four  drones  (although  tracking  performance  was  better  when  con¬ 
trolling  two  drones).  At  the  middle  level  of  automation,  control  by  a 
course  autopilot,  acceptability  of  performance  depended  on  the  standaixJ 
applied  and  the  number  of  drones  under  control. 

Platform  and  watching.  Figure  15.6  shows  performance  on  the  plat¬ 
form  and  watching  tasks  as  a  function  of  tracking  condition.  In  either 
task,  performance  reflected  the  difficulty  of  the  tracking  task;  that  is, 
performance  on  both  the  platform  and  the  watching  task  improved  when 
more  tracking  automation  was  provided  or  when  the  number  of  drones 
was  reduced  from  four  to  two.  For  both  tasks,  performance  was  accept¬ 
able  except  in  the  most  difficult  tracking  condition  (controlling  four 
drones  by  rudder).  For  all  other  conditions,  the  reaction  times  to  plat¬ 
form  alarms  and  the  number  of  missed  target  arrows  were  acceptable. 
Strict  standards,  however,  were  available  for  the  watching  task  only. 

Mental  workload.  Figure  15.7  shows  the  average  level  of  mental 
workload  reported  by  the  subjects.  Mental  workload  decreased  if  the 
level  of  automation  was  increased  or  if  the  number  of  drones  was  re¬ 
duced  from  four  to  two.  Mental  workload  was  close  to  the  maximum 
for  the  most  difficult  condition;  mental  workload  never  exceeded  a  level 
of  ’’slightly  above  medium"  for  the  other  conditions. 

DISCUSSION 

The  conclusion  of  the  study  is  that  one  operator  can  do  more  for  the 
system  than  just  providing  intervention  in  extraordinary  situations, 
such  as  platform  damage  or  collision  avoidance.  The  operators  were  able 
to  monitor  the  drones'  platforms  adequately  and  to  watch  out  for  other 
traffic;  moreover,  the  operators  had  sufficient  spare  capacity  to  control 
four  drones  at  once  using  a  course  autopilot.  The  fact  that  their  tracking 
performance  was  not  always  acceptable  is  probably  irrelevant  consider¬ 
ing  that  real  operators  will  have  more  experience  and,  hence,  will  meet 
all  operational  criteria. 

The  operators  rated  the  combined  level  of  mental  workload  when  per¬ 
forming  these  tasks  simultaneously  as  ’’slightly  above  medium."  When 
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Figure  15.6.  Performance  on  the  platform  and  the  watching  tasks  as  a  function  of  the  automation  of  the 
task  with  control  of  two  drones  or  four  drones.  (The  dashed  line  shows  the  boundaries  of  operational  acceptal 
the  watching  task.) 
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Figure  15.7.  Mental  workload  for  the  various  conditions  of  the  drone- 
control  task. 


a  path  predictor  was  available,  tracking  performance  was  excellent  and 
the  operators  estimated  their  workload  as  low,  perhaps  too  low. 

Operator  capacity  comes  in  units,  not  in  fractions.  At  initial  alloca¬ 
tion,  the  system  may  need  the  fraction,  but  still  gets  the  unit.  The  posi¬ 
tion  advocated  in  the  present  paper  is  to  use  the  available  operator  ca¬ 
pacity  in  the  best  possible  way.  It  would  be  unwise  to  load  human 
operators  to  the  limits  of  their  mental  capacity,  because  this  deprives 
the  system  of  safety  margins.  It  would  be  equally  unwise,  however,  to 
undems,&  the  human  operators.  Mental  capacity  is  a  valuable  system 
resource.  Using  this  resource  a  little  more  does  not  increase  the  person¬ 
nel  requirements,  can  save  costly  automation,  and  can  provide  the  opera¬ 
tor  with  a  more  satisfying  job. 
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FUNCTION  ALLOCATION  IN  ARMY  SYSTEMS' 

J.*P.  Papin  and  J.-Y.  Ruisseau 


During  the  design  of  a  modern  system,  the  crucial  problem  arises 
of  knowing  who  {which  member  of  the  crew  or  which  automaton) 
does  what  (function  to  be  fidfilled).  Today,  decisions  on  function 
allocation  can  be  made  using  a  scientific  approach.  The  Human 
Factors  Center  of  the  French  Army  is  trying  currently  to  put  in 
place  a  standard  approach.  This  approach  is  based  on  an  analysis 
of  the  requirement,  followed  by  an  analysis  of  functions  indepen¬ 
dent  (as  much  as  possible)  of  specific  technical  solutions.  The 
process  is  completed  by  analyzing  the  work  of  crews  in 
operational  systems  similar  to  the  planned  system.  From  there,  it 
is  possible  to  perform  computer  modelling  of  a  typical  scenario  in 
which  the  elementary  activities  that  must  be  brought  into  play  in 
the  system  are  represented.  Different  combinations  of  these 
activities  are  arranged  to  be  performed  by  an  operator  (human  or 
automatic)  in  order  to  find  an  optimal  solution  for  the  allocation 
of  functions.  Although  simple  in  theory,  this  approach  is  actually 
complex  to  put  into  practice  because  the  human  activities  that 
must  be  performed  to  fulfil  a  given  task  depend  very  much  on  the 
interface  chosen  and  thi4s  on  a  particular  technical  solution.  That 
is  why  the  approach  of  optimizing  the  system  must  be  continued 
during  the  product  development  phase.  This  can  be  done  by 
validation  using  functional  computer-based  mock-ups.  The 
methods  employed  are:  the  analysis  of  tasks  for  systems  .similar  to 
the  future  system  (e.g.,  helicopters):  the  analysis  of  requirements: 
the  analysis  of  functions  during  development,  taking  into  account 
technical  solutions  that  are  imposed  (e.g.,  reconnaissance 
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vehicle,  command  post  vehicle):  computer  modelling  of  the 
scenario  (e.g.,  tank,  reconnaissance  vehicle,  helicopters): 
computer  modelling  of  the  workstation  (e.g.,  command  post 
vehicle,  gunner);  future  dynamic  software  modelling;  and  direction 
of  manikins  by  software  such  as  MicroSAlNT. 


INTRODUCTION 

The  design  of  modem  weapon  systems  poses  the  problem  of  the  divi¬ 
sion  of  roles  among  humans  and  machine:  who  (operator,  automaton, 
crew)  does  what  (fulfils  a  function,  for  example).  Today,  a  scientific 
approach  can  be  used  to  make  decisions  on  the  allocation  of  the  diverse 
functions  at  the  heart  of  a  system.  This  approach  must  be  integrated 
with  the  general  approach  to  design  in  a  systematic  fashion,  to  produce 
solutions  based  as  much  on  system  architecture  as  on  allocation  of 
function. 

The  Human  Factors  Center  of  the  French  Army  currently  works  in 
this  way  and  has  put  in  place  a  standardized  approach  based  on  an  analy¬ 
sis  of  needs  involving  a  functional  analysis  independent  of  probable 
technical  solutions  or  possibilities.  An  analysis  of  tasks  based  on  a 
system  similar  to  the  planned  system  permits  the  possibilities  for  the 
future  system  to  be  envisaged.  These  possibilities  can  be  understood  in 
terms  of  elementary  activities,  representing  the  likely  future  activities, 
and  modelled  in  the  form  of  various  types  of  scenario  that  reflect  the 
operational  requirement. 

Various  computer  tools  currently  permit  at  least  partial  responses  to 
the  problems  thus  raised,  and  allow  solutions  to  be  proposed  to  the 
designers  that  respond  as  well  as  possible  to  overall  constraints — issues 
that  are  as  much  operational  as  technical. 

ANALYSIS  OF  THE  REQUIREMENT 

The  first  step  in  the  design  of  a  new  system  is  an  analysis  of  the  re¬ 
quirement.  This  is  a  familiar  practice  for  the  ergonomist  because  analy¬ 
sis  of  requirements  is  a  fundamental  principle  of  an  ergonomics  inter¬ 
vention,  with  known  scope  and  extent;  however,  analysis  of 
requirements  is  sometimes  much  less  in  evidence  in  the  world  of  engi- 
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necrs  and  operators.  It  falls  to  the  lot  of  the  human  factors  specialist  to 
highlight  the  importance  of  this  step  in  the  ease  of  the  human.  In  ef¬ 
fect,  the  human  is  today,  and  will  remain  for  a  long  time,  a  major  de¬ 
termining  element  in  the  development  of  a  weapon  system. 

An  example  of  this  approach  can  be  seen  in  the  ease  of  the  modular 
armored  vehicle  (VBM)  project.  The  goal  of  this  project  is  to  procure 
for  the  Army  a  family  of  vehicles  suited  to  a  range  of  operational  needs: 
infantry  troop  transport,  command  post,  weapons  carriage,  direct  fire 
vehicle,  etc.  In  the  ease  of  the  VBM,  an  initial  analysis  of  the  require¬ 
ment  was  based  on  an  analysis  of  the  current  limitations  of  vehicles 
that  meet  these  operational  needs  only  partially,  and  on  an  analysis  of 
evolutions  in  design  concepts  that  arc  likely  in  the  medium  term.  From 
that  analysis,  we  extracted  the  principal  factors  before  orienting  our 
thinking.  Thus,  it  appeared  that,  in  a  personnel  carrier  version  (VTT),  it 
was  difficult  to  consider  separating  the  two  functions  of  the  vehicle 
commander:  to  command  the  vehicle  and  to  command  the  embarked 
combat  group.  This  had  a  marked  influence  on  the  design  of  the  future 
vehicle. 


FUNCTION  ANALYSIS 

An  analysis  of  the  requirement  brings  out  the  principal  constraints 
that  affect  the  system  and  its  overall  performance.  Function  analysis 
makes  it  possible  to  determine  the  principal  functions  the  system  must 
provide,  how  to  provide  them,  and  under  what  environmental  conditions 
they  can  be  assured.  It  also  allows  at  least  an  initial  attempt  at  defining 
the  allocation  of  the  various  functions  between  human  and  machine.  At 
this  level,  it  is  a  case  of  knowing  what  has  to  be  done  and  how  it  has  to 
be  done  to  ensure  the  optimal  effectiveness  of  the  system. 

An  example  of  such  an  analysis  is  provided  again  by  the  VBM  proj¬ 
ect.  The  principal  missions  that  could  be  committed  to  each  clement  of 
the  VBM  family  were  defined,  analyzed,  and  validated  at  the  operational 
level.  Each  function  necessary  for  the  accomplishment  of  a  mission  was 
identified,  and  the  constraints  eharaetcri/ing  each  function  were  exam¬ 
ined.  This  process  was  carried  out  for  all  the  requirements  specified  for 
the  family  of  vehicles,  which  permitted  a  precise  determination  of  the 
directions  to  be  followed  in  defining  the  design  more  closely.  Among 
other  things,  the  choice  of  certain  technical  solutions  followed  directly 
from  this  analysis,  whether  it  was  for  the  purely  system  portions 
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(functions,  mobility,  fire,  protection)  or  the  portion  better  labelled 
“human”  (ergonomics,  human  factors,  etc.).  An  example  of  such  a 
choice  is  the  determination  of  the  rear-opening  doors  in  the  personnel 
carrier  version.  There  were  two  opposing  concepts  for  this  design  ele¬ 
ment:  the  technical  viewpoint  directed  solutions  toward  a  system  of  two 
doors,  while  the  operational  viewpoint  directed  solutions  toward  an  in¬ 
clined  ramp.  A  good  choice  should  favor  the  operational  considerations. 
Currently,  without  anticipating  the  solution  that  will  finally  be  adopted 
for  the  vehicle,  one  can  see  clearly  that  the  analysis  carried  out,  sup¬ 
ported  by  full-scale  mock-up  trials  of  the  different  designs,  makes  it 
possible  to  establish  directions  for  the  designer  based  on  both  technical 
and  operational  arguments. 

ANALYSIS  OF  TASKS  FOR  A  SIMILAR  SYSTEM 

Another  step  involves  the  analysis  of  tasks  to  determine  the  probable 
future  activity  of  the  operators  in  the  planned  system.  This  analysis  can 
be  performed  in  the  abstract  by  considering  the  direct  results  of  the 
analysis  of  requirements  and  the  function  analysis,  but  it  can  also  be 
built  in  a  comparative  way  by  analyzing  existing  systems  that  provide  a 
partial  solution  to  the  problems  posed.  Knowledge  of  equivalent  sys¬ 
tems  can  be  of  great  help  in  this  stage. 

An  example  of  this  process  can  be  found  in  the  Nuclear,  Biological, 
Chemical  Reconnaissance  Vehicle  program  (VAB  Reco  NBC),  which  is 
currently  entering  the  production  stage.  In  this  case,  the  task  analysis 
was  conducted  using  elements  representing  parts  of  the  future  system, 
pulling  together  the  principal  components.  This  analysis  included  each 
member  of  the  crew  (four  in  all)  and  permitted  a  better  organization  of 
the  operators  at  the  heart  of  the  system.  In  particular,  certain  constraints 
appeared  to  be  defining  ones  for  the  technical  system  and  motivated 
some  major  changes  in  the  allocation  of  certain  functions  to  one  opera¬ 
tor  or  another.  Among  these  defining  elements  was  the  need  for  the 
commander  of  the  vehicle  to  have  at  hand  a  control  screen  for  the  proc¬ 
esses  under  way  (which  was  not  identified  in  the  analysis  of  require¬ 
ments  or  the  function  analysis).  This  constraint  had  important  repercus¬ 
sions  for  the  overall  design  for  the  system,  as  well  as  for  the  design  for 
the  commander’s  position. 

This  same  approach  is  being  applied  in  another  context,  directed  at 
determining  the  actual  constraints  involved  in  personnel  selection  for 
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two  systems  under  study  (the  Leclerc  tank  and  the  Tiger  combat  heli¬ 
copter).  Current  research  concerning  the  selection  and  training  of  pilots 
for  the  future  Tiger,  for  example,  leads  us  to  consider  in  a  global  man¬ 
ner  the  problem  of  transfer  of  training.  Should  pilots  be  trained  and  then 
be  given  a  conversion  course  for  the  new  system,  or  should  novice  pi¬ 
lots  be  trained  on  the  new  system?  The  task  analyses  for  two  systems 
(the  Gazelle,  old  and  well  known,  and  the  Tiger,  a  future  system  still  in 
the  prototype  stage)  have  brought  out  a  number  of  differences  between 
the  two  systems,  due  primarily  to  the  technological  differences  between 
them.  It  seems  that  the  distinction  between  the  roles,  not  to  say  the 
functions,  of  the  commander  and  the  pilot  is  likely  to  be  much  more 
pronounced  in  the  new  system  than  in  the  old.  This  specialization  may 
require  different  aptitudes  for  each  member  of  the  crew,  depending  on  the 
overall  mission  to  be  accomplished. 

RETROSPECTIVE  FUNCTION  ANALYSIS 

The  idea  of  retrospective  function  analysis,  which  we  developed  re¬ 
cently,  is  a  mixture  of  work  analysis  and  function  analysis.  This  step  is 
of  interest  when,  for  example,  the  aim  is  to  partially  automate  or 
mechanize  a  task  that  is  currently  performed  using  manual  tools  but 
that  involves  major  health  risks. 

The  example  presented  here  concerns  mine-clearing  operations  per¬ 
formed  by  engineering  sappers.  In  the  first  step,  a  detailed  analysis  of 
the  work  was  undertaken,  then  the  actions  identified  were  translated  into 
‘‘solution’’  functions.  We  then  searched  to  identify  the  function  of  the 
next  highest  level  to  which  the  solution  function  belonged.  Next,  we 
constructed  a  tree  of  the  functions,  moving  up  as  high  as  possible  to 
build  the  principal  function.  The  latter  was  then  broken  down  into  pos¬ 
sible  solution  functions.  For  example,  we  found  a  solution  function 
“sweeping  with  the  aid  of  a  brush,”  and  another  solution  function, 
“feeling  the  ground  with  the  aid  of  a  probe.”  These  two  functions  had 
the  goal  of  detecting  and  recognizing  a  mine  in  the  ground.  The  ques¬ 
tion  was  posed  whether  it  was  possible  to  perform  this  detection  iind 
recognition  in  a  single  operation  with  the  help  of  a  tool  handled  from  a 
distance.  This  work  led  us  to  develop  a  mechanical  probe  based  on  nee¬ 
dles,  which  can  be  used  from  a  distance  away.  Thus,  it  will  be  possible 
to  gather  in  a  single  action  the  shape  and  other  physical  characteristics 
of  an  object. 
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This  example  shows  how  one  can  transform  part  of  the  mental  proc¬ 
ess  through  which  the  sapper,  by  many  probes  of  the  ground,  constructs 
a  mental  image  to  identify  the  objeet,  by  presenting  the  operator  with 
an  image  giving  form  to  the  objeet. 

MODELLING  THE  SCENARIO 

Task  analysis  permits  us  to  obtain  an  overall  vision  of  the  aetivity  of 
operators  at  the  heart  of  any  particular  system.  It  then  becomes  feasible, 
when  one  is  able  to  eharacterize  precisely  each  task  and  the  links  be¬ 
tween  tasks,  to  create  a  functional  model  of  the  overall  system  through 
the  appropriate  simulation  tools.  Such  modelling  is  available  with 
tools  like  Micros AINT,  which  we  have  been  using  for  several  years  in 
this  type  of  proeess. 

The  results  obtained  permit  us  to  validate  the  initial  alloeation  of 
funetions  and  the  division  of  tasks  between  human  and  maehine  as  well 
as  the  arrangement  of  the  tasks,  and  also  to  know  the  influence  of  varia¬ 
tions  in  the  parameters  of  certain  tasks  (duration,  type  of  link,  level  of 
the  task,  etc.)  on  the  overall  performance  of  the  system.  In  the  case  of 
the  VAB  Reco  NBC,  such  modelling  permitted  us  to  validate  the  target 
duration  of  a  single  mission  of  the  vehicle,  for  which  the  initial  charac- 
teristies  had  been  estimated  (but  not  entirely  on  the  basis  of  technical 
information  or  known  operations)  and  to  show  that  modifications 
should  be  made.  In  fact,  in  the  first  simulations  made,  the  workload  of 
certain  op>erators  was  close  to  100  percent,  while  others  had  a  very  lim¬ 
ited  workload.  A  better  division  of  functions  permitted  us  to  reduce  this 
diffenenee. 


MODELLING  WORKSTATIONS 

Another  aspect  of  modelling  environmental  constraints  concerns  the 
geometry  and  dimensions  of  workstations.  Several  points  can  be  made 
about  this  process.  The  principal  point  concerns  the  geometrical  model¬ 
ling  of  the  human  operator,  entirely  separate  from  the  work  situation  in 
which  the  operator  is  involved.  Such  modelling  makes  it  possible  to 
determine  anthropometric  constraints  and  dimensions  based  on  the  an¬ 
thropometry  of  the  subjects  and  on  the  specific  population  from  which 
the  users  are  drawn.  We  ean  also  extraet  the  postures,  the  constraints  on 
reach,  and  the  constraints  on  vision  from  the  anthropometry  of  the  sub- 
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jects  or  from  the  dimensions  of  the  workstations  themselves.  For  this 
analysis,  we  use  a  computer  program  for  human  modelling  (Safework) 
that  allows  the  creation  of  manikins  that  can  be  adjusted  at  will,  as  well 
as  the  creation  (or  the  importation  from  a  CAD  system)  of  workplace 
details.  The  manikins  thus  created  can  be  positioned  in  their  working 
environment  in  a  simple,  intuitive  manner.  It  is  therefore  easy  to  check 
or  to  validate,  depending  on  the  case,  the  suitability  of  the  proposed 
technical  solutions.  This  approach  has  been  used  for  several  different 
projects,  such  as  the  command  post  vehicle  (VAB  SIR),  for  example, 
for  which  a  detailed  analysis  of  the  working  environment  of  the  opera¬ 
tors  is  in  progress.  In  this  case,  we  have  demonstrated  the  postural  con¬ 
straints  associated  with  the  design  of  the  commander’s  position  and  the 
radio  operator’s  position.  This  analysis  allows  us  to  provide  guidance 
for  designs  that  influence  the  overall  activity  of  the  operators  and,  in  the 
end,  the  efficiency  of  the  design  itself.  The  designer  can  thus  reassess 
certain  elements  of  the  design  and  seek  solutions  that  are  more  optimal. 

RAPID  PROTOTYPING 

Even  further  along  in  the  process  of  defining  designs  and  optimizing 
the  allocation  of  functions  at  the  heart  of  a  weapon  system,  today  vir¬ 
tual  reality  permits  us  to  simulate,  in  “real  size”  and  at  less  cost,  com¬ 
plex  situations  in  which  the  operator  is  an  indispensable  element  in  the 
control  loop.  It  is  possible  to  define  a  virtual  environment  in  enough 
detail  to  give  a  certain  realism  to  the  simulation  generated,  and  to  per¬ 
mit  the  operator  to  carry  out  drills  in  a  configuration  close  to  that  of  the 
future  system.  Nevertheless,  one  must  beware  of  hasty  interpretations 
of  the  results  of  such  experiments,  since  it  is  not  always  easy  to  con¬ 
firm  the  validity  of  the  situation  simulated  with  respect  to  reality.  One 
must  also  take  into  account  problems  of  transfer  of  training  in  the  per¬ 
formance  of  tasks  in  the  two  different  worlds,  the  virtual  world  and  the 
real  world. 


COMPUTER  DIRECTION  OF 
MANIKINS  (MicroSAINT) 

Finally,  other  operators  can  be  incorporated  into  simulations  such  as 
those  described  above  using  manikins  directed  by  tools  that  generate 
scenarios.  This  is  one  route  we  are  exploring  at  the  moment.  Our  prin- 
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cipal  objective  is  to  be  able  to  direct  a  Safe  work  manikin,  for  example, 
using  behavioral  data  provided  by  MicroSAINT  or  other  products.  We 
envision  primarily:  data  on  human  movement;  data  on  the  physical 
effort  the  operator  can  exert;  or  data  on  mechanical  constraints  placed  on 
operators  in  the  execution  of  their  tasks  (in  terms  of  postural  stability). 
We  will  thus  have  access  to  the  ultimate  phase  of  simulation,  which 
will  permit:  validation  of  the  processes  for  allocation  of  functions  at  the 
heart  of  the  system  being  designed;  knowledge  of  the  interplay,  in  real 
time,  among  the  ensemble  of  situations  and  behaviors,  which  will  al¬ 
low  the  functioning  of  the  system  to  be  understood;  and  the  extraction 
of  important  strengths  and  weaknesses  in  design  solutions.  This  seems 
very  futuristic  now,  but  it  is  the  promise  offered  by  the  possibilities  of 
technology  in  the  very  near  term. 
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DISCUSSION  AND  CONCLUSIONS 


The  aims  of  the  Workshop  on  Improving  Function  Allocation  for  Inte¬ 
grated  Systems  Design  were: 

•  to  review  the  need  for  function  allocation; 

•  to  review  the  maturity  of  available  techniques  and  to  make  recom¬ 
mendations  to  human  factors  practitioners; 

•  to  identify  the  need  for  additional  research  in  the  area. 

The  need  for  function  allocation  and  the  maturity  of  available  tech¬ 
niques  were  addressed  in  the  discussions  that  concluded  each  paper  ses¬ 
sion.  A  final  discussion  session  was  used  to  identify  promising  devel¬ 
opments  in  function  allocation  and  topics  for  further  research. 

THE  NEED  FOR  FUNCTION  ALLOCATION 

The  workshop  participants  endorsed  the  importance  of  function  allo¬ 
cation  to  the  system  development  process.  Function  allocation  deci¬ 
sions  define  the  roles,  functions,  and  tasks  performed  by  human  opera¬ 
tors  and  maintainers. 

Thus,  function  allocation  is  related  to  issues  of  automation  and  per¬ 
sonnel  reduction,  as  well  as  to  questions  about  human  responsibility  for 
the  safe  and  effective  operation  of  a  system.  The  steadily  improving 
capabilities  of  hardware  and  software  complicate  decisions  about  how  to 
balance  human  factors  considerations  against  political,  financial,  mana¬ 
gerial,  and  performance  constraints.  A  formal  review  of  those  issues  is 
essential,  and  function  allocation  provides  that  review. 

Function  allocation  issues  involve  many  criteria,  including:  the 
number  of  personnel  and  their  rank,  experience,  and  training;  technical 
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feasibility,  costs,  and  subsystem  performance;  and  commercial,  legal, 
and  cultural  constraints. 

Workshop  participants  recognized  that  function  allocation  is  a  design 
solution  which  is  achieved  as  part  of  the  creative  process  in  developing 
a  system  design.  This  solution  includes  expectancies  about  how  the 
system  will  perform.  Such  expectancies  must  be  tested,  the  conse¬ 
quences  for  the  human  operator  must  be  evaluated,  and  the  allocation  of 
functions  reviewed  and  revised  in  a  tightly  coupled,  iterative  process. 

MATURITY  OF  TECHNIQUES 

Overall,  the  workshop  papers  demonstrated  that  human  factors  engi¬ 
neering  issues  associated  with  function  allocation  are  being  recognized 
and  that  current  human  factors  engineering  techniques  are  being  applied. 
If  one  judges  by  the  papers,  however,  little  research  activity  is  being 
devoted  currently  to  human  behavior  in  systems  operation  or  to  improv¬ 
ing  human  factors  engineering  techniques. 

For  example,  no  new  major  developments  in  function  allocation  were 
reported  at  the  workshop,  although  several  potentially  promising  means 
for  improving  function  allocation  decisions  were  mentioned  in  the  dis¬ 
cussions.  These  included  the  application  of  principles  used  in  computer 
science  for  the  allocation  of  functions  in  distributed  software  systems. 
Other  principles  might  be  available  from  resource  allocation  techniques 
used  for  factory  and  plant  layout  and  production  line  scheduling. 

The  approaches  to  making  function  allocation  decisions  that  were 
reported  at  the  workshop  included: 

•  a  simple  dichotomous  choice  between  human  and  machine; 

•  a  two-stage  allocation  process; 

•  iterative  modification  of  function  allocations;  and 

•  reverse  engineering  of  operator  tasks. 

The  criteria  that  participants  reported  they  had  used  for  making  func¬ 
tion  allocation  decisions  fell  into  the  categories  of  performance,  cost, 
technical  feasibility,  and  health  and  safety.  These  criteria  are  recom¬ 
mended  already  in  the  human  factors  literature.  Teamwork  was  high¬ 
lighted  as  an  important  criterion  in  some  presentations  and  discussions. 
The  need  to  achieve  a  dynamic  allocation  of  functions  was  supported  by 
reports  that  “static”  allocations  of  function  do  not  work  well  in  some 
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systems.  This  is  because  there  are  changes  in  the  allocation  of  functions 
between  team  operators  during  long  missions.  Many  operational  sys¬ 
tems  involve  missions  lasting  several  days,  and  a  single,  slatie  alloca¬ 
tion  of  functions  is  inappropriate  for  such  systems. 

Overall,  most  approaches  to  function  allocation  reported  at  the  work¬ 
shop  focused  on  evaluating  the  implications  of  the  allocation  decision 
for  system  performance  and  operator  workload,  rather  than  on  making 
the  decision  itself. 

This  may  reflect  predictive  weakness  in  available  function  allocation 
techniques;  more  likely,  it  reflects  the  many  criteria  that  arc  involved  in 
the  decision.  A  function  allocation  decision  can  be  evaluated  only  in  the 
context  of  its  consequences  for  the  operator’s  tasks,  workload,  and  re¬ 
sulting  performance.  Methods  that  were  reviewed  for  evaluating  impli¬ 
cations  of  function  allocation  decisions  included: 

•  fast-time  computer  simulations  of  operator  tasks  and  workload; 

•  human-in-thc-l(x>p  simulation; 

•  rapid  prototyping;  and 

•  virtual-reality  prototyping. 


RECOMMENDATIONS  TO  PRACTITIONERS 

The  following  recommendations  to  practitioners  were  enumerated 
during  the  discussions. 

1.  Function  allocation  is  essentially  a  creative  process  associated  with 
the  design  of  a  system.  As  such,  function  allocation  does  not  lend  itself 
to  a  mechanistic  approach  or  to  automation,  although  computer-based 
tools  can  facilitate  the  process. 

2.  It  is  important  that  human  factors  specialists  establish  their  meth¬ 
odology  for  implementing  function  allocation  within  the  constraints 
posed  by  a  particular  project.  Integrated  design  teams  such  as  those  de¬ 
scribed  in  the  paper  by  McDaniel  provide  the  working  climate  necessary 
for  the  early  and  effective  interchange  of  data  and  concepts  on  the  role  of 
the  human. 

3.  To  assist  the  interchange  of  such  data  and  concepts,  practitioners 
should  select  approaches  to  function  allocation  that  are  understandable 
by  systems  engineers  and  designers.  Because  computer  scientists,  sys¬ 
tems  engineers,  and  human  factors  specialists  use  the  term  function 
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allocation  to  denote  different  activities,  and  because  the  terms  function 
and  task  have  different  meanings  depending  on  the  user,  practitioners 
should  employ  clearly  understood,  common  definitions  of  such  terms. 

4.  No  one  function  allocation  technique  can  be  recommended  for  use 
by  practitioners.  Several  viable  approaches  for  function  allocation  are 
available  and  can  contribute  to  the  development  of  advanced  systems 
provided  they  are  applied  at  the  correct  point  in  the  systems  engineering 
process. 


NEED  FOR  RESEARCH 

The  workshop  generated  a  number  of  suggestions  for  research,  as 
follows. 

1.  A  high  priority  was  assigned  to  research  leading  to  the  develop¬ 
ment  of  a  taxonomy  of  function  allocation  issues.  The  goal  would  be  to 
produce  a  taxonomy  relating  three  aspects  of  function  allocation:  the 
problem  domain,  the  criteria  involved  in  function  allocation,  and  the 
techniques  appropriate  to  function  allocation  in  that  domain.  The  prob¬ 
lem  domain  would  cover:  the  type  of  system,  whether  human/human, 
human/machine,  machine/machine;  the  system  functions;  and  the  func¬ 
tion  allocations.  The  criteria  involved  in  function  allocation  would  in¬ 
clude  political,  organi^ational,  technical,  and  financial  aspects  of  the 
system.  The  appropriate  techniques  should  encompass  an  essential  set 
of  paper-and-pencil  techniques  as  well  as  emerging  technology  such  as 
virtual  prototyping.  This  research  will  also  require  the  compilation  of 
lessons  learned  from  function  allocation. 

2.  A  suggestion  related  to  the  development  of  the  above  taxonomy 
was  the  need  for  research  to  understand  the  creative  aspects  of  the  design 
process  that  apply  to  complex  systems. 

3.  Recommendations  for  the  development  of  improved  methods  of 
function  allocation  included  the  use  of  genetic  algorithms.  Such  algo¬ 
rithms  can  optimize  a  function  when  an  explicit  model  is  lacking.  They 
might  be  used  to  optimize  the  human-machine  system  by  linking  op¬ 
erator  capabilities  to  system  functions. 

4.  A  high  priority  was  placed  on  research  into  predicting  and  measur¬ 
ing  operator  workload;  this  emphasis  reflects  the  importance  of  testing 
or  evaluating  function  allocation  decisions.  Such  research  should  inves¬ 
tigate  a  number  of  topics,  including: 
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•  the  use  of  human-in-the-loop  part-task  simulation; 

•  the  use  of  computer  simulations  of  networks  of  operator  tasks  for 
representing  human  behavior  (skill,  rule,  and  knowledge  based); 

•  the  validity  of  current  workload  prediction  techniques; 

•  the  relationship  of  operator  workload  to  system  perfonnance;  and 

•  the  validity  of  extrapolating  from  such  predictions  to  conclusions 
about  system  performance. 

5.  A  high  priority  was  also  given  to  research  related  to  adaptive  allo¬ 
cation  of  functions.  The  function  allocation  process  has  to  cater  to  crcw 
systems  in  which  operators  may  pass  responsibility  for  specific  func¬ 
tions  from  one  to  another. 

6.  The  function  allocation  process  must  also  cater  to  the  adaptive 
allocation  of  functions  between  humans  and  machines.  Modeling  of  the 
operator  to  permit  function  reallocation  based  on  the  machine’s  model 
of  the  operator  was  seen  as  an  important  research  topic;  decision  aiding 
was  another. 

7.  One  of  the  major  research  issues  raised  in  the  discussions  was  the 
role  of  humans  in  advanced  systems.  How  should  humans  and  machines 
work  together  collaboratively?  Questions  posed  by  Fitts  and  his  col¬ 
leagues  in  1951  still  lack  general  answers.  Should  the  human  monitor 
the  system,  given  that  humans  are  poor  monitors?  Should  the  system 
monitor  the  human?  If  so,  what  roles  should  humans  play  and  what  arc 
their  responsibilities?  Arc  humans  included  in  systems  Just  to  deal  with 
those  functions  that  engineers  cannot  automate?  Opinions  on  decision 
making  ranged  from  the  principle  that  the  human  should  make  all  deci¬ 
sions,  because  humans  are  responsible  for  systems,  to  the  principle  that 
there  arc  some  decisions  that  humans  should  never  be  pcmiittcd  to 
make.  For  example,  the  “20  minute  rule”  prevents  humans  from  inter¬ 
vening  for  20  minutes  in  the  event  of  the  activation  of  the  automatic- 
safety  system  of  a  nuclear  power  station. 

8.  There  arc  ethical  issues  as.scx:iatcd  with  these  questions  that  tire 
particularly  important  in  the  design  of  weapon  systems.  “Human  fail¬ 
ures”  such  as  recent  well-publicized  incidents  in  which  friendly  forces  or 
noncombatanls  have  been  attacked  can  be  attributed  to,  and  arc  consid¬ 
ered  to  be  the  responsibility  of,  the  command  chain.  To  whom  should 
the  failure  of  a  highly  automated  .system  be  attributed  when  that  system 
is  designed  to  mexlify  its  behavior  on  the  basis  of  experience  and  the 
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specific  situation  being  played  out?  This  question  deserves  more  atten¬ 
tion  from  all  those  responsible  for  the  development  and  procurement  of 

advanced  weapon  systems. 

CONCLUSIONS  AND  RECOMMENDATIONS 

•  Because  the  human  operator  is  increasingly  a  limited  and  expensive 
resource,  and  because  the  human  elements  have  a  large  influence  on 
system  life-cycle  costs  and  system  effectiveness,  the  allocation  of 
functions  between  humans  and  machines  is  of  major  concern  in  the 
design  of  advanced  systems. 

•  Function  allocation  is  not  an  isolated  activity,  but  is  intrinsic  to  an 
iterative  process  of  analysis/design/evaluation  for  developing  hu¬ 
man-machine  systems.  Function  allocation  must  be  incorporated 
into  the  development  process  early  enough  to  influence  design  deci¬ 
sions  and  to  permit  iteration. 

•  No  single  technique  is  available  that  deals  with  all  of  the  issues 
involved  in  assigning  functions  to  humans.  Function  allocation  in¬ 
cludes  issues  of:  system  effectiveness;  reliability;  cost;  feasible 
level  of  automation;  personnel  selection,  training,  and  experience; 
team  effectiveness;  and  economic,  political,  and  cultural  con¬ 
straints. 

•  Because  available  allocation  techniques  are  essentially  qualitative, 
function  allocation  decisions  must  be  validated  by  predictions  of 
operator  workload  or  system  performance,  and  the  allocation  deci¬ 
sions  revised  if  necessary.  Within  the  iterative  design  process,  func¬ 
tion  allocation  itself  must  be  iterated  to  evaluate  and  refine  the  de¬ 
cisions  made. 

•  Research  is  required  to  support  the  development  of  a  taxonomy  of 
function  allocation  issues  that  relates  factors  affecting  function  al¬ 
location  to  the  problem  domain  and  to  available  function  allocation 
techniques. 

•  To  provide  more  rigorous  means  of  validating  function  allocation 
decisions,  research  is  needed  into:  the  validity  of  current  workload 
prediction  techniques;  the  relationship  of  workload  to  system  per¬ 
formance;  the  use  of  computer  simulations  of  networks  of  operator 
tasks;  the  validity  of  extrapolating  from  such  predictions  to  conclu- 
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sions  about  system  performance;  and  the  potential  of  virtual  reality 
simulations  for  validating  design  decisions. 

•  The  development  of  advanced  technology  involving  decision  aids 
and/or  autonomous  decision  subsystems  poses  problems  concern¬ 
ing  the  roles  and  functions  of  humans  that  arc  not  fully  understo(xi 
at  this  time.  Caution  must  he  exercised  in  the  implementation  of 
such  technology. 


Appendix  I 


SOME  BASIC  QUESTIONS  IN  DESIGNING 
AN  AIR-NAVIGATION  AND 
TRAFFIC-CONTROL  SYSTEM' 


In  planning  a  long-range  research  program  on  human  factors  in  air- 
navigation  and  traffic  control,  it  is  necessary  to  make  some  predica¬ 
tions  about  the  role  human  beings  will  play  in  the  system  of  the  future. 
This  is  obviously  a  very  difficult  kind  of  forecasting  to  do,  but  the 
things  that  psychologists  know  about  human  capabilities  and  limita¬ 
tions  enable  us  to  make  some  general  statements  on  this  point.  Consid¬ 
eration  of  this  very  basic  question  will  also  point  up  some  important 
problems  for  future  research. 

POSSIBLE  ROLES  OF  THE  HUMAN  OPERATOR 

IN  FUTURE  AIR-TRAFFIC-CONTROL  AND  NAVIGATION 

SYSTEMS 

One  way  of  approaching  this  problem  of  forecasting  the  directions  of 
future  developments  is  to  ask:  What  roles  can  the  human  be  as¬ 
signed  in  future  systems?  Four  possible  kinds  of  control  systems, 
distinguished  in  terms  of  the  degree  of  human  participation  in  the  con¬ 
trol  process,  can  be  postulated.  We  list  these  only  in  order  to  illustrate 
the  range  of  possibilities.  We  do  not  wish  to  imply  that  they  all  are 
equally  feasible  or  desirable. 

y.  Fully  Automatic  Control.  To  some  people  automatic  flight  and 
automatic  traffic  control  appears  to  be  the  direction  that  future  develop¬ 
ments  will  take.  Our  society  is  continually  becoming  more  highly 


*  From  Human  engineering  for  an  effective  air-navigation  and  traffic- 
control  system  (pp.  31-56),  by  P.  M.  Fitts  (Ed.),  1951,  Washington,  DC: 
National  Research  Council. 
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mechanized.  Automatic  machinery  opens  doors  for  us;  enables  us  to 
communicate  with  each  other  in  a  matter  of  seconds  though  we  may  be 
separated  by  miles;  provides  signals  for  our  rail  and  highway  traffic;  and 
solves  mathematical  and  logical  problems  of  such  speed  that  the  lay¬ 
man’s  imagination  is  overwhelmed.  If  this  is  the  ultimate  direction  in 
which  air  navigation  and  traffic  control  developments  will  go,  then  there 
will  be  no  human  operators  in  the  control  system  of  the  future,  and 
human-engineering  will  be  concerned  with  problems  of  production  and 
maintenance,  rather  operational  problems. 

2.  Automatic  Control  with  Human  Monitoring,  Another  possibility  is 
that  human  operators  will  always  have  to  be  around  to  take  over  in  an 
emergency  even  though  the  equipment  be  fully  automatic.  Machines  are 
not  infallible.  Dial  telephone  systems,  for  example,  sometimes  break 
down — tubes  burn  out,  relays  need  replacing,  wires  deteriorate.  Even  if 
the  primary  task  of  the  human  becomes  that  of  monitoring,  maintain¬ 
ing,  and  calibrating  automatic  machines,  some  men  will  need  to  be 
capable  of  making  intelligent  decisions  and  taking  quick  action  in  cases 
of  machine  breakdown  or  in  unforeseen  emergencies. 

The  human-engineering  research  problems  relating  to  such  a  control 
system  would  center  about  the  capabilities  of  the  human  as  a  monitor, 
as  a  trouble-detector,  and  as  an  emergency  controller,  both  on  the  ground 
and  in  the  air. 

3.  Semi-Automatic  Control  Supplemented  by  Human  Performance  of 
Critical  Functions.  Another  possibility  is  that  the  human  may  routinely 
perform  certain  critical  functions,  leaving  the  major  work  of  the  system 
to  semi-automatic  machinery.  If  this  turns  out  to  be  the  case,  then  long- 
range  research  on  human  functions  would  center  about  those  higher-level 
mental  functions  we  call  reasoning,  judgment,  planning,  and  decision 
making.  It  would  emphasize  the  problems  of  information  display  and 
communication. 

4.  Primary  Control  by  Human  Operators  Who  Would  be  Assisted  by 
Effective  Data- Analysis,  Data-Trans  miss  ion,  and  Data-Display  Equip¬ 
ment.  Still  another  possibility  that  we  must  consider  is  that  the  role  of 
the  human  in  the  future  traffic-control  system  will  resemble  the  role  he 
performs  at  present.  Human  operators  may  do  most  of  the  critical 
tasks — sizing  up  display  information,  receiving  and  issuing  communica¬ 
tions,  making  decisions,  and  issuing  directions — aided  by  much  better 
data-displays,  communication  links,  computers,  and  other  equipment, 
than  present-day  controllers  have. 
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DIVISION  OF  RESPONSIBILITY 
BETWEEN  MEN  AND  MACHINES 

Some  general  answers  to  the  problem  of  deciding  the  proper  role  of 
human  operators  in  a  control  system  can  be  made  on  the  basis  of  what 
psychologists  know  at  the  present  time  about  the  limiting  characteris¬ 
tics  of  human  capacity  and  performance. 

In  some  cases,  our  information  on  these  points  is  fairly  complete;  in 
others,  we  must  characterize  the  statements  as  being  little  better  than 
informed  opinions.  In  discussing  these  broad  questions  we  have  at¬ 
tempted  to  indicate  what  answers  are  based  on  well-established  experi¬ 
mental  evidence,  and  what  on  informed  opinion. 

SOME  GENERAL  CHARACTERISTICS  OF 
HUMAN  PERFORMANCE  THAT  HELP  DEFINE 
THE  ROLE  OF  THE  HUMAN 

Alertness.  In  considering  the  possible  role  of  the  human  in  an  air- 
navigation  and  traffic-control  system  we  know  that  certain  allocations  of 
responsibility  would  not  be  desirable  because  of  human  limitations.  The 
second  alternative  listed  above,  automatic  control  with  human  monitor¬ 
ing,  often  might  not  work  well  because  there  is  evidence  that  in  certain 
kinds  of  tasks  humans  are  poor  monitors.  In  tasks  that  call  for  long 
periods  of  relative  inactivity,  humans  tend  to  become  inattentive,  and 
bored,  and  sometimes  fall  asleep  Mackworth,  1948,  1950).  Even  if 
the  system  were  arranged  to  force  the  attention  of  the  human  monitor  at 
the  lime  of  equipment  failure,  his  immediate  reactions  might  be  far  from 
adequate. 

One  premise  we  have  assumed  in  considering  this  kind  of  system  is 
that  the  human  should  be  prepared  to  take  over  critical  functions  of  air- 
traffic  control  in  case  of  emergency.  But  a  man  cannot  make  intelligent 
decisions  in  an  emergency  unless  he  has  an  adequate  understanding  of  the 
traffic  picture  at  the  moment  of  the  emergency  and  for  a  short  time  pre¬ 
ceding  it. 

Thus,  we  are  forced  to  conclude  that  the  monitor  must  keep  alert  and 
thoroughly  informed  of  the  traffic  situation  at  all  times  in  order  that  he 
can  take  over  in  emergencies,  we  must  also  conclude  that  a  monitoring 
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system  is  one  of  the  worst  kinds  of  work  situations  when  we  want  the 
human  to  stay  alert. 

The  railroads  long  ago  separated  the  functions  of  expediting  traffic  and 
of  monitoring  for  possible  collisions,  giving  responsibility  for  the  for¬ 
mer  to  men  and  for  the  latter  primarily  to  automatic  machines. 

It  is  true,  of  course,  that  men  do  perform  many  monitoring  tasks  in 
modem  industry.  Electrical  substations,  for  example,  are  monitored  by 
men.  Also,  even  though  men  may  be  inherently  poor  monitors  it  is 
possible  that  in  certain  special  cases  they  might  be  more  dependable 
monitors  than  machines. 

Considerations  such  as  these  lead  us  to  the  following  two  conclusions 
which  we  believe  to  be  well  supported  by  present  knowledge:  (J)  Human 
tasks  should  provide  activity.  The  roles  of  the  human  operators  in  the 
future  air  navigation  and  traffic  control  system  should  be  active  rather 
than  passive  ones.  Activity  in  any  task  is  conducive  to  alertness,  and 
helps  to  insure  that  the  human  will  keep  abreast  of  the  situation.  Activ¬ 
ity  also  is  conducive  to  learning  and  maintenance  of  proficiency.  (2) 
Human  tasks  should  be  intrinsically  interesting.  The  role  of  the  hu¬ 
man  in  any  system  should  be  intrinsically  interesting  in  order  for  human 
efficiency  to  remain  at  a  high  level.  Although  there  is  no  simple  set  of 
rules  for  making  human  jobs  interesting,  a  great  deal  that  we  already 
know  can  be  applied  to  this  problem. 

Overloading.  A  second  consideration  relating  to  the  role  of  the  human 
operator  is  the  question  of  whether  humans  or  machines  should  be  as¬ 
signed  to  tasks  in  which  they  may  be  "ganged  up  on"  or  overloaded.  Our 
information  here  is  very  sketchy  indeed.  We  do  know  that  humans  are 
notoriously  variable  in  their  behavior  under  conditions  of  extreme  stress. 
Some  break  down  completely;  others  turn  out  a  creditable  {performance 
even  under  exceedingly  adverse  conditions.  However,  complex  machines 
may  also  break  down  under  such  conditions. 

There  is  some  evidence  to  suggest  that  under  overload  conditions  a 
human,  in  some  ways,  {performs  better  than  does  a  machine.  Under  dis¬ 
aster  conditions,  as  an  illustration,  automatic  dial  telephone  systems  arc 
known  to  have  broken  down  completely  under  overload  conditions 
when,  according  to  informed  opinions,  human  switchboard  o{Perators 
would  have  been  able  to  get  at  least  some  calls  through.  Whether  this  is 
a  universal  generalization  we  can  make  about  comparative  man -machine 
performance  is  highly  problematical,  but  we  should  at  least  not  discard 
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completely  the  idea  that  in  some  ways  humans  may  function  better  than 
machines  under  stress  conditions. 

Fallibility.  The  final  consideration  which  needs  mention  is  the  rela¬ 
tive  fallibility  of  a  man  to  a  machine.  Machines  are  by  no  means  infal¬ 
lible,  but  in  general  they  can  be  made  to  carry  out  specific  functions 
with  fewer  errors  than  would  be  made  by  humans.  This  raises  the  ques¬ 
tion  of  whether  safety  should  depend  on  human  alertness  and  decision 
making  or  on  automatic  machines.  Our  answer  to  this  is  an  unqualified 
assertion  that  the  primary  responsibility  for  safety  in  air  traffic  control 
should  not  rest  primarily  on  humans.  This  leads  to  another  imjx)rtant 
working  principle. 

It  is  our  conclusion,  based  on  what  we  know  about  human  abilities, 
that  as  a  rule  machines  should  monitor  men.  We  suggest  as  an  impor¬ 
tant  working  principle  that  checking,  verifying,  and  monitoring  equip¬ 
ment  be  devised  that  will  make  it  impossible  for  any  human  in  an  air¬ 
craft  or  on  the  ground  to  violate  basic  safety  rules,  such  as  assigning 
two  aircraft  to  the  same  block  of  space.  This  is  the  reverse  of  the  eoni- 
monly-expresscd  idea  that  men  should  monitor  machines.  We  are  sug¬ 
gesting  that  in  general  machines  should  monitor  humans. 

WHAT  CAN  MEN  DO  BETTER  THAN  MACHINES? 

In  our  search  for  a  general  answer  to  the  problem  of  dividing  respon¬ 
sibility  between  men  and  machines,  it  would  help  us  considerably  if  we 
could  find  some  general  answers  to  the  problem  of  what  people  can  do 
better  than  machines,  and  vice  versa.  A  listing  of  those  respects  in 
which  human  capabilities  surpass  those  of  machines  must,  of  course,  be 
hedged  with  the  statement  that  we  cannot  foresee  what  machines  can  be 
built  to  do  in  the  future. 

1.  Serrsory  functions.  One  respect  in  which  human  capacities  often 
surpass  those  of  instruments  is  in  the  sensory  functions.  This  is  espe¬ 
cially  true  of  absolute  sensory  thresholds,  i.e.  the  minimum  absolute 
energy  necessary  for  sensory  detection.  The  human  eye,  for  example,  is 
capable  of  detecting  the  flare  of  a  match  15  miles  away  on  a  dark  night. 
It  can  detect  the  presence  of  a  black  wire,  l/16th  inch  in  diameter,  viewed 
against  the  clear  sky  a  quarter  of  a  mile  away.  The  human  ear  is  so  sen¬ 
sitive  that  it  can  almost  detect  the  random  collisions  of  molecules  of  air. 
It  is  far  more  efficient  at  low  energy  levels  than  any  existing  micro¬ 
phone.  On  the  other  hand,  machines  can  be  designed  to  respond  to  en- 
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ergy  outside  the  wavelength  bands  to  which  our  eyes  and  ears  are  sensi¬ 
tive.  We  shall  not  dwell  on  this  problem  any  longer  except  to  point  out 
that  psychologists,  physiologists,  and  physicists  have  accumulated  a 
vast  amount  of  basic  information  about  human  sensory  capacities.  It  is 
one  of  the  areas  in  which  many  facts  are  known.  Design  engineers  who 
have  particular  problems  in  this  area  can  easily  secure  the  information 
they  need  by  consulting  industrial  or  engineering  psychologists.  (See, 
for  example,  the  Tufts  College  Handbook  of  Human  Engineering  Data.) 

2.  Perceptual  abilities.  Closely  related  to  the  above  is  the  superiority 
of  the  human  in  perceptual  abilities,  particularly  with  regard  to  what 
psychologists  call  stimulus  generalization.  As  an  illustration,  nearly 
every  time  you  see  your  car  you  see  it  under  varying  conditions  of  illu¬ 
minations,  with  varying  amounts  of  dust  on  it,  and  from  different  an¬ 
gles.  Yet  you  ordinarily  have  no  difficulty  at  all  in  distinguishing  it 
from  other  cars.  In  other  words,  you  generalize  your  memory  of  your 
own  car  and  recognize  it  even  though  the  energy  pattern  acting  on  your 
eyes  is  always  different.  Abstract  conceptual  qualities  like  squareness, 
roundness,  triangularity,  are  easily  grasped  and  used  hy  the  normal  per¬ 
son  even  though  triangles,  for  example,  come  in  an  infinitude  of  shapes. 
We  should  note  that  engineers  have  not  succeeded  in  producing  instru¬ 
ments  which  have  the  versatility  of  the  human  in  these  capacities.  The 
conclusion  here  is  that  a  human  is  very^  good  at  sizing  up  complex  situa¬ 
tions  quickly,  especially  if  data  are  encoded  and  displayed  in  such  a 
way  that  he  can  use  perceptual  capacity  to  the  maximum  (i.e.  if  ade¬ 
quate  ’^pictorial"  or  familiar  "patterned"'  displays  are  used.) 

3.  Flexibility.  Another  special  capacity  of  the  human  is  his  extraordi¬ 
nary  flexibility  and  ability  to  improvise.  These  abilities  are  still  incom¬ 
pletely  understood  by  psychologists,  but  they  represent  important  rc- 
speets  in  which  humans  surpass  machines.  The  amount  of  flexibility  a 
machine  has  is  fixed  hy  the  amount  that  was  huilt  into  it.  The  machine 
will  attempt  as  many  different  kinds  of  solutions  as  its  designer  planned 
for  and  no  more.  Experiments  on  complex  problem-solving  in  humans, 
on  the  other  hand,  show  that  humans  may  attempt  many  different  solu¬ 
tions  for  the  same  problem — just  think  of  the  number  of  ways  in  which 
this  paragraph  could  have  been  written  to  convey  essentially  the  same 
point.  Flexibility  is  especially  important  in  a  changing  and  evolving 
system,  such  as  one  in  which  new  techniques  are  constantly  coming 
into  use.  It  also  provides  insurance  against  complete  breakdown  in 
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emergencies.  The  conclusion  here  is  that  if  flexibility  in  a  system  is 
important,  it  probably  is  a  good  plan  to  let  human  beings  play  an  impor¬ 
tant  role  in  the  systenu 

4.  Judgment  and  Selective  Recall.  The  nebulous  ability  we  eall 
judgment  also  appears  to  be  unique  in  the  human.  In  large  part,  judg¬ 
ment  is  due  to  the  superior  ability  of  the  human  to  store  large  amounts 
of  information  and  to  pull  appropriate  information  out  of  long-term 
storage  at  the  appropriate  time.  This  is  what  we  ordinarily  call  memory. 
People  do  not  remember  everything  they  see,  hear,  or  learn:  but  the 
things  that  are  remembered  are  somehow  integrated  with  the  mass  of 
material  already  there  and  are  available  for  recall  years  later. 

Good  judgment  is  a  crystallization  based  on  experiences  which  resem¬ 
ble,  but  are  not  quite  the  same  as,  the  situation  facing  a  person  now.  An 
experieneed  eontroller  may  have  an  emergency  situation  which  is  not 
exactly  like  any  other  emergency  he  has  ever  seen.  But  if  he  has  been 
properly  selected  and  trained,  he  is  capable  of  drawing  upon  similar  ex¬ 
periences  he  has  seen,  or  merely  heard  about,  and  of  exercising  gocxi 
judgment  in  facing  the  present  emergency.  This  kind  of  ability  has  not 
yet  been  built  into  a  machine. 

Machines  can  be  constructed  with  memories,  it  is  true,  but  the  ma¬ 
chines  so  far  devised  are  not  very  efficient  at  the  kind  of  selective,  long¬ 
term  storage  needed  in  handling  unique  problems.  The  conclusion  here 
is  that  to  the  degree  that  we  fail  to  reduce  all  operations  to  logical, 
pre-set  procedures,  we  need  people  around  who  can  make  judgments. 

5.  Reasoning.  As  we  shall  see  later,  automatic  computers  are  superior 
in  speed  and  accuracy  to  human  brains  in  deductive  reasoning,  but  no 
success  has  been  attained  in  constructing  a  machine  which  can  perform 
inductive  reasoning.  Inductive  reasoning  is  that  peculiar  ability  which 
mathematicians  and  scientists  use  when  they  formulate  new  principles 
on  the  basis  of  masses  of  empirical  data.  The  original  idea  that  formed 
the  basis  for  Einstein’s  theory  is  an  example  of  inductive  reasoning 
although  many  of  the  later  refinements  of  the  theory  probably  have 
resulted  from  the  process  of  deduction. 

In  summary  then,  we  can  see  that  the  human  carries  within  him  some 
remarkable  powers  that  cannot  yet  be  duplicated  by  machines,  espe¬ 
cially  abilities  needed  to  deal  with  changing  situations  and  unforeseen 
problems. 
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WHAT  CAN  MACHINES  DO  BETTER  THAN  MEN? 

Humans,  however,  do  have  many  faults  as  well  as  good  points  and  it 
behooves  us  to  list  these  as  well.  In  general,  machines  exeel  humans  in 
the  kinds  of  things  we  have  already  turned  over  to  them  in  our  society — 
especially  tasks  requiring  great  strength,  and  tasks  of  a  very  routine 
nature. 

y.  Speed  and  Power,  Although  machines  do  not  have  many  of  the 
sensory  and  perceptual  capacities  that  humans  do,  they  far  exeel  {people 
in  the  ability  to  respond  quickly  and  powerfully.  Even  under  ideal  condi« 
tions  a  man  requires  over  0. 1  second  b>efore  he  can  start  to  move  a  con¬ 
trol  in  response  to  a  signal,  while  in  most  normal  work  situations  his 
lag  time  is  even  longer.  Milton  and  others  (1947),  for  example,  meas¬ 
ured  pilot  reaction  time  in  the  air  and  found  an  average  lag  of  1.55  sec¬ 
onds  before  they  initiated  a  movement  in  instrument  recovery  problems. 
The  time  was  1 .35  seconds  for  contact  recoveries.  In  these  experiments 
pilots  were  blindfolded  and  disoriented,  then  shown  either  their  instru¬ 
ment  panel  or  the  ground  and  asked  to  re-orient  and  level  the  aircraft.  An 
auto  pilot  would,  of  course,  respond  much  more  quickly.  Machines  can 
he  devised  to  make  movements  smoother,  faster,  and  with  greater  power 
than  humans. 

2.  Routine  Work.  Machines  excel  humans  in  repetitive,  routine 
tasks.  Machines  can  be  counted  on  to  make  fewer  errors  in  routine 
tasks,  and  to  turn  out  responses  that  not  only  are  quicker,  hut  are  far 
more  uniform  than  a  person  can  make.  They  also  do  not  become  boned 
and  inattentive. 

3.  Computation,  Machines  are  more  efficient  computers  than  hu¬ 
mans — no  matter  whether  the  computations  are  simple  or  complex.  In 
the  latter  ease,  a  machine  can  examine  all  the  possible  deductions  from 
sets  of  postulates,  reject  those  which  are  invalid,  and  act  upon  those 
which  are  valid.  It  is  important  to  remember,  however,  that  the  rules  of 
operation,  the  postulates,  must  be  built  into  the  machine. 

4.  Short-term  Storage.  Machines  appear  to  exeel  humans  in  short¬ 
term  memory.  There  are  many  jobs  in  our  present  society  that  call  for 
short-term  storage  of  information,  followed  hy  complete  erasure  of  the 
data  in  preparation  for  another  task.  Machines  can  be  huilt  with  this 
kind  of  memory.  Humans,  on  the  other  hand,  are  not  so  good  at  it.  They 
especially  have  difficulty  in  completely  erasing  information  in  short¬ 
term  storage.  Also,  it  is  sometimes  difficult  to  be  sure  that  a  man  has 
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noticed  and  remembered  a  particular  fact — this  is  why  controllers  often 
ask  pilots  to  verify  that  they  have  understood  certain  critical  infonna- 
tion. 

5.  Simultaneous  Activities.  Finally,  a  complex  machine  is  capable  of 
carrying  on  more  different  activities  simultaneously  than  is  a  single 
human  being.  We  arc  talking  here  about  decisions  and  activities  requir¬ 
ing  some  degree  of  attention — not  reflex  or  automatic  processes  like 
breathing.  There  is  much  information  to  indicate  that  when  he  has  to 
employ  his  highest  intellectual  abilities  man  is  essentially  a  one- 
ehannel  computer — he  can  only  work  effectively  at  solving  one  problem 
or  attending  to  one  thing  at  a  time.  Only  when  activities  have  been 
greatly  over-learned  can  he  do  several  things  at  once  very  effectively  and 
even  then  he  may  actually  have  to  shift  back  and  forth  rapidly  between 
the  two  activities.  The  only  way  to  get  around  this  human  limitation  is 
by  adding  more  men  to  do  the  job. 

These  are  some  of  the  things  we  can  say  with  confidence  about  the 
relative  abilities  of  men  and  machines.  They  provide  a  starting  point, 
However,  it  is  obvious  that  we  need  much  more  information  of  this 
sort — more  specific  information  about  human  capabilities  and  limita¬ 
tions  in  performing  different  tasks — before  we  can  determine  the  opti¬ 
mum  division  of  labor  between  men  and  machines. 

We  turn  next  to  the  question  of  division  of  responsibility  between 
different  human  beings  in  the  air  navigation  and  traffic-control  system. 

DIVISION  OF  PRIMARY  RESPONSIBILITY 
BETWEEN  HUMAN  OPERATORS 

In  any  efficient  air-navigation  and  trafllc-control  system  there  must  be 
a  clear  division  of  primary  responsibilities  between  the  different  human 
beings  in  the  system.  The  exact  nature  of  their  responsibilities  cannot 
be  determined  without  knowledge  of  the  equipment  in  the  system;  nor 
can  the  nature  of  the  equipment  that  will  give  optimum  system  per¬ 
formance  be  determined  without  some  consideration  of  what  the  respon¬ 
sibilities  of  various  human  beings  will  be.  Very  little  research  data  arc 
available  as  a  guide  to  decisions  of  this  sort.  However,  some  general 
principles  can  be  suggested  on  the  basis  of  what  we  know  about  human 
characteristics. 

How  to  divide  responsibility  between  all  of  the  people  working  on 
the  ground  versus  all  of  those  working  in  the  air  is  a  very  important 
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matter.  It  is  also  a  very  difficult  problem  to  answer.  The  techniques  of 
systems  research,  which  arc  discussed  in  a  later  section,  can  be  applied 
to  this  kind  of  problem. 

This  particular  problem  is  so  broad,  however,  that  it  will  be  very 
difficult  even  by  these  techniques  to  secure  conclusive  answers.  Among 
the  difficulties  confronting  the  research  worker  arc  those  of  changing 
operational  conditions,  or  even  of  simulating  different  conditions,  in 
order  to  try  out  different  allocations  of  responsibility.  It  will  also  be 
very  difficult  to  insure  that  each  condition  is  tried  out  impartially  and 
the  results  measured  objectively.  It  is  our  conclusion  that  extensive  use 
should  be  made  of  expert  consultants,  including  Industrial  Psychologists 
and  Engineering  Psychologists,  in  arriving  at  decisions  about  the  alloca* 
tion  of  major  responsibilities  of  this  sort.  Research  on  certain  aspects  of 
the  general  problem  is  also  indicated. 

Tbe  problems  of  allocating  responsibilities  within  a  group  of  different 
human  operators  doing  closely  related  tasks  are  similar  to  tho.se  just 
considered.  These  problems  include  the  division  of  work  load  between  a 
pilot  and  co-pilot,  or  between  two  ground  controllers.  In  this  case,  it 
will  be  easier  to  conduct  systems  research.  The  systems  to  be  studied  are 
smaller  and  this  makes  simulation,  systematic  variation,  and  measure¬ 
ment  easier.  Problems  at  this  level,  whether  they  involve  operational 
procedures,  human-engineering  improvements,  or  requirements  for  fu¬ 
ture  equipment,  can  usually  be  studied  by  the  technique  outlined  in  the 
later  section  on  systems  research. 

Fortunately,  we  already  know  a  good  deal  about  some  of  the  factors 
that  determine  how  many  and  what  kinds  of  things  one  individual  can 
do,  and  there  arc  a  few  general  rules  for  dividing  responsibilities  between 
different  men,  and  between  men  and  machines.  Here  arc  two  useful  prin¬ 
ciples. 

/.  Who  should  make  decisions.  Other  things  being  equal,  the  person 
who  is  informed  is  obviously  the  best  person  to  make  decisions.  A 
related  principle  is  that  decisions  should  be  made  near  the  point  where 
basic  information  is  derived — thus  minimizing  extensive  communica¬ 
tion  links.  Pilots  have  direct  access  to  local  air-derived  information, 
such  as  data  about  the  aircraft's  altitude,  about  operating  conditions 
about  icing  conditions,  and  about  the  amount  of  gasoline  remaining. 
They  arc  the  logical  people  to  make  on-the-spot  flight  and  navigation 
decisions.  Ground  controllers  have  direct  access  to  ground -derived  and 
ground-stored  information.  They  are  informed  about  meteorological 
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conditions,  traffic  loads,  and  schedules  over  a  wide  area.  They  are  the 
logical  people  to  plan,  coordinate,  and  expedite  the  flow  of  traffic.  In 
both  cases,  however  they  should  have  all  possible  aid  in  analysis  and 
computation,  whether  this  is  accomplished  by  other  men  or  by  ma¬ 
chines.  Data-gathering  and  decision-making  should  be  carefully  coordi¬ 
nated. 

2.  Equalizing  work  loads.  Usually  the  most  effective  division  of  re¬ 
sponsibility,  is  one  in  which  the  work  load  is  equitably  shared  by  asso¬ 
ciated  workers.  The  future  traffic-control  system  must  not  overload  the 
single  pilot  of  a  jet  fighter,  but  at  the  same  time  it  should  permit  effi¬ 
cient  use  of  several  persons  on  large  transports.  Often  problems  of  work 
assignment  can  be  clarified  by  determining  the  number  of  different  tasks 
performed  by  a  particular  person  and  the  relative  importance  of  each 
task.  The  pilot  who  is  making  an  instrument  approach,  for  example,  is 
a  very  busy  man. 

Two  methods  have  been  developed  recently  for  reducing  the  work  load 
of  the  pilot  in  this  particular  situation.  One  method  is  for  a  radar  (GCA) 
operator  on  the  ground  to  monitor  the  plane's  position  in  azimuth  and  in 
elevation  during  its  approach  and  periodically  to  give  the  pilot  headings 
and  rates  of  descent  to  fly.  This  relieves  the  pilot  of  one  series  of  activi¬ 
ties,  that  of  cross-checking  course-deviation  and  heading  and  deciding 
which  heading  to  fly. 

The  other  method  is  to  provide  the  pilot  with  an  airborne  computer  of 
the  "Zero  Reader”  type  that  will  tell  him  what  bank  and  pitch  changes  to 
make  from  moment  to  moment  in  order  to  stay  on  the  correct  approach 
path.  Other  ways  of  simplifying  the  pilot’s  task  during  an  instrument 
approach  are  undoubtedly  possible.  The  point  here  is  that  we  cannot 
expect  a  system  to  work  if  we  overload  one  man. 

SOME  IMPORTANT  ISSUES  NOT  DIRECTLY  DEALT 
WITH  IN  THIS  REPORT 

This  is  a  good  place  to  mention  several  issues  that  are  of  importance 
for  human  engineering,  but  are  not  directly  dealt  with  in  this  report. 

Technical  Feasibility 

Research  in  human  engineering  should  keep  abreast  of  new  engineer¬ 
ing  techniques,  and  new  equipment  developments  if  it  is  to  foresee  hu- 
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man  operator  problems  and  provide  information  in  time  to  influence  the 
design  of  new  items.  Although  this  kind  of  background  information  has 
been  considered  in  preparing  the  present  report,  it  is  not  discussed  ex¬ 
plicitly. 

Economic  Issues 

Decisions  about  what  human  operators  will  do  and  what  machines 
will  do  in  any  particular  system  involve  balancing  the  increases  in 
safety  and  efficiency  against  monetary  costs.  For  any  fixed  amount  of 
money  that  can  be  invested  in  a  man-machine  system  there  is  probably  a 
unique  combination  of  human  and  machine  elements  that  will  maximize 
efficiency.  Human-engineering  research  can  furnish  part  of  the  data 
needed  to  determine  this  optimum  combination,  but  again,  we  have 
avoided  any  discussion  of  these  economic  problems. 

Manpower  and  Other  Personnel  Problems 

Many  different  human  activities  are  involved  in  designing,  producing, 
and  maintaining  a  man-machine  system  as  well  as  in  operating  it. 

Training.  Manpower  costs  include  those  of  training.  Training  costs 
may  be  high  or  low,  depending  on  the  design  characteristics  of  the 
equipment  that  men  must  learn  to  operate.  As  an  illustration,  our 
analysis  of  present  air-route-traffic-control  centers  revealed  wide 
dissatisfaction  with  the  new  flight  progress  boards.  In  most  centers  these 
boards  are  arranged  in  such  a  way  that  the  assistant  cannot  see  what  the 
controller  is  doing.  For  this  reason  he  cannot  assist  the  controller  in 
many  important  aspects  of  his  work,  and  receives  little  on-the-job 
training  as  a  controller.  Because  of  this,  the  CAA  may  soon  have  to 
establish  special  schools  for  training  controllers,  whereas  the  older  type 
of  boards  were  well  suited  for  in-service  training.  Similar  problems  arise 
whenever  pilots  or  ground  personnel  are  trained  on  the  Job.  Training 
time  is  an  important  criterion  for  the  design  of  many  items  of 
equipment. 

Maintenance  of  Skills.  Tasks  can  be  set  up  so  that  human  operators 
eventually  become  deficient  in  certain  important  skills  which  are  infre¬ 
quently  used.  As  an  illustration,  a  pilot  who  relies  too  much  on  the 
auto-pilot  may  lose  some  of  his  skill  in  manual  control,  or  one  who 
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routinely  uses  automatic  landing  equipment  may  lose  his  skill  in  mak¬ 
ing  manual  landings.  This  in  turn  creates  special  training  problems^ 
particularly  training  for  emergency  operations.  We  have  not  considered 
this  problem  directly,  but  it  is  another  criterion  forjudging  the  goodness 
of  equipment  design. 

Job  Life.  Still  another  aspect  of  the  manpower  problem  is  the  effect 
that  equipment  design  may  have  on  the  number  of  years  during  which  a 
man  can  hold  a  particular  job  or  series  of  related  jobs.  Most  traffic  con¬ 
trollers  today  believe  that  their  jobs  can  be  done  only  by  fairly  young 
men.  Many  controllers  told  us  that  fifteen  years  is  considered  a  long 
time  to  work  as  a  traffic  controller.  Also  there  are  few  opportunities  for 
advancement.  It  is  obviously  a  waste  of  manpower  if  workers  become 
unable  to  hold  their  jobs  after  such  a  short  work  life,  unless  these  work¬ 
ers  can  move  on  to  other  jobs  where  they  can  utilize  their  experience  . 

Equipment  Maintenance  and  Calibration.  All  equipment,  especially 
complex  automatic  equipment,  requires  human  maintenance,  calibration, 
and  checking.  It  is  obviously  important  to  design  equipment  so  that 
maintenance  time  is  minimized,  and  few  human  errors  are  made  in  ad¬ 
justing  machines.  In  this  connection  we  want  to  point  out  the  similarity 
in  consequence  of  calibration  and  maintenance  errors  on  the  one  hand, 
and  errors  made  by  human  beings  using  nonautomatic  equipment,  on  the 
other  hand.  All  sources  of  human  error  will  not  be  eliminated  by  going 
over  to  automatic  equipment. 

Although  this  report  does  not  deal  in  detail  with  these  problems,  all 
of  the  manpower  and  personnel  factors  mentioned  above — initial  train¬ 
ing,  maintenance  of  proficiency,  life  span  of  operators,  and  equipment 
maintenance — must  be  considered  in  planning  for  an  efficient  man- 
machine  system.  In  this  regard  the  research  programs  on  personnel  and 
training  problems  in  aviation  will  contribute  to  the  engineering  devel¬ 
opment  program. 


SUMMARY 

Men  versus  Machines.  In  this  section  we  have  considered  the  roles 
men  and  machines  should  have  in  the  future  air  navigation  and  traffic 
control  system.  We  have  surveyed  the  kinds  of  things  men  can  do  better 
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than  present-day  machines,  and  vice  versa.  Humans  appear  to  surpass 
present-day  machines  in  respect  to  the  following: 

1.  Ability  to  detect  small  amount  of  visual  or  acoustic  energy. 

2.  Ability  to  perceive  patterns  of  light  or  sound. 

3.  Ability  to  improvise  and  use  flexible  procedures. 

4.  Ability  to  store  very  large  amounts  of  information  for  long 

periods  and  to  recall  relevant  facts  at  the  appropriate  time. 

5.  Ability  to  reason  inductively. 

6.  Ability  to  exercise  judgment. 

Present-day  machines  appear  to  surpass  humans  in  respect  to  the  follow¬ 
ing: 

1.  Ability  to  respond  quickly  to  control  signals,  and  to  apply 

great  force  smoothly  and  precisely. 

2.  Ability  to  perform  repetitive,  routine  tasks. 

3.  Ability  to  store  information  briefly  and  then  to  erase  it  com¬ 

pletely. 

4.  Ability  to  reason  deductively,  including  computational  abil¬ 

ity. 

5.  Ability  to  handle  highly  complex  operations,  i.e.  to  do  many 

different  things  at  once. 

Monitoring.  We  believe  that  men,  on  the  whole,  are  poor  monitors. 
We  suggest  that  great  caution  be  exercised  in  assuming  that  men  can 
successfully  monitor  complex  automatic  machines  and  "take  over"  if  the 
machine  breaks  down.  We  believe  that  engineers  should  seriously  con¬ 
sider  systems  in  which  machines  would  monitor  men,  especially 
in  respect  to  matters  of  safety,  and  prevent  them  from  making  serious 
mistakes. 

Overloading.  Both  men  and  machines  are  likely  to  break  down  or 
become  unstable  if  overloaded.  Men  are  subject  to  emotional  stress 
caused  by  personal  problems  and  other  off-the-job  influences.  However, 
it  is  possible  that  in  some  ways  humans  can  do  a  better  job  than  ma¬ 
chines  under  overload,  or  stress,  conditions  arising  on  the  job — at  least 
they  may  supplement  machines  in  this  regard,  especially  in  situations 
where  flexibility  is  an  asset. 
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Flexibility.  One  of  the  greatest  benefits  to  be  gained  from  including 
human  elements  in  a  system  is  increased  flexibility  in  adapting  to 
changing  demands.  A  proficient  and  well-trained  human  operator  usually 
can  adapt  readily  to  the  introduction  of  new  equipment,  to  the  sudden 
failure  of  equipment,  or  to  the  occurrence  of  a  unique  and  unforeseen 
problem.  This  particular  human  capacity  can  be  utilized  to  the  fullest 
only  if  the  overall  system  is  properly  human-engineered. 

Research  Implications.  Most  of  the  general  research  objectives  that 
we  consider  in  the  following  sections  arc  not  tied  to  any  particular  as¬ 
sumption  as  to  what  the  role  of  the  human  operator  in  the  future  air- 
navigation  and  traffic-control  system  will  be. 

In  some  cases  this  has  prevented  us  from  formulating  research  rec¬ 
ommendations  in  as  specific  terms  as  we  could  have  had  we  been  con¬ 
cerned,  for  example,  only  with  the  present  system. 

Instead  of  trying  to  be  unduly  specific,  we  have  tried  to  think  in  tenns 
of  functions  that  may  be  performed  hy  human  controllers  in  any  system. 
In  most  cases,  suggestions  for  research  arc  slanted  towards  general  hu¬ 
man  behavior  in  broad  contexts.  Information  derived  from  such  research 
programs  will  not  only  be  applicable  to  equipment  of  a  certain  kind  and 
date,  but  will  anticipate  problems  and  solutions  in  connection  with 
future  equipment. 


RECOMMENDATION 

It  appears  likely,  that  for  a  good  many  years  to  come,  human  beings 
will  have  intensive  duties  in  relation  to  air  navigation  and  traffic  con¬ 
trol.  It  is  extremely  important  that  sound  decisions  be  made  regarding 
what  these  duties  should  be.  As  we  have  indicated  in  the  present  chapter, 
many  of  the  facts  that  we  know  about  human  beings  arc  pertinent  to 
decisions  about  the  division  of  labor  between  men  and  machines.  We 
suggest  later  (sec  Research  Objective  IX,  Problem  Area  I')  that  human 
engineering  consultants  can  be  of  great  assistance  when  plans  for  new 
systems  arc  being  made.  Even  though  the  problems  arc  exceedingly 
broad,  we  believe  that  very  worthwhile  progress  can  be  made  by  research 


'  Editors'  note:  This  proposal  for  research  deals  with  the  utilization  of  hu¬ 
man-engineering  data;  a  proposed  project  would  seek  the  help  of  experts  in 
making  decisions  about  how  best  to  utilize  human  abilities  in  an  air- 
navigation  and  traffic-control  system. 
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in  this  area,  especially  by  the  systematic  analysis  of  various  kinds  of 
data  that  are  already  available  in  aviation  and  in  industry.  Therefore,  wc 
recommend  the  following  research  objective: 

Research  Objective  L  Determination  of  the  Relative  Abilities  of  Men 
and  Machines  to  Perform  Critical  Functions  in  Air-Navigation  and 
Traffic -Control  Systems. 

Basic  research  should  be  supported  to  provide  the  principles  on  which 
decisions  about  the  most  effective  roles  of  men  and  machines  can  be 
based.  The  decision  to  develop  a  machine  that  will  reform  a  certain  op¬ 
eration  usually  implies  a  prior  decision  that  a  machine  can  do  the  job 
better,  faster,  or  more  reliably  than  a  man.  At  the  recent  time  there  arc 
few  rules  that  can  be  followed  in  reaching  such  decisions.  Information  is 
needed  about  such  general  topics  as  these: 

a.  What  standards  or  norms  of  human  performance  can  be 
expected  when  men  are  assigned  certain  air-navigation  and 
traffic-control  tasks  and  how  much  variability  will  there  be  be¬ 
tween  individuals  in  the  performance  of  these  tasks? 

b.  To  what  extent  will  the  various  human  tasks  require  unusual 
human  capacities,  and  long  training  programs? 

c.  How  can  human  performance  be  measured  in  terms  that  will 
permit  the  meaningful  comparison  of  the  effectiveness  of  men 
and  of  particular  machines  when  carrying  out  certain  tasks? 

Collection  and  synthesis  of  known  facts  about  human  abilities  will 
help  to  establish  some  of  the  needed  principles.  Some  of  the  informa¬ 
tion  necessary  for  answering  additional  questions  can  be  obtained  from 
existing  records  or  can  be  collected  during  routine  operations.  In  other 
instances,  it  may  be  necessary  to  conduct  extensive  experiments  to  es¬ 
tablish  some  of  the  principles  that  are  needed  in  this  area. 

Illustrative  Research  Problems.  In  this  report  we  have  advanced  ar¬ 
guments  in  support  of  the  hypothesis  that  men  cannot  efficiently  moni¬ 
tor  automatic  equipment.  This  hypothesis  needs  to  be  tested  in  various 
work  situations,  and  it  may  be  that  the  answer  can  be  found  by  careful 
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surveys  of  typieal  industrial  situations,  such  as  power  plants  or  military 
lookout  posts,  where  men  are  now  employed  as  monitors. 

As  another  example,  in  this  report  we  propose  the  hypothesis  that 
under  eertain  circumstances  men  may  function  better  than  machines 
under  eonditions  of  overload  and  stress.  This  hypothesis  needs  to  be 
validated,  and  again  the  answers  may  be  fortheoming  from  a  careful 
analysis  of  records  from  the  operation  of  automatie  machinery,  sueh  as 
dial  telephone  systems,  during  wartime  eonditions,  floods,  partial  power 
failures,  ete. 
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